|
839 | 839 | MUST act as follows:
|
840 | 840 | p>
|
841 | 841 | <ol class="algorithm">
|
| 842 | + <li>If the method was not <a>triggered by user activationa>, return |
| 843 | + a promise rejected with a "<a>SecurityErrora>" <a>DOMExceptiona> |
| 844 | + and terminate this algorithm. |
| 845 | + li> |
842 | 846 | <li>Let <var>requestvar> be the <a>PaymentRequesta> object on
|
843 | 847 | which the method is called.
|
844 | 848 | li>
|
|
856 | 860 | Optionally, if the <a>user agenta> wishes to disallow the call
|
857 | 861 | to <a>show()a> to protect the user, then return a promise
|
858 | 862 | rejected with a "<a>SecurityErrora>" <a>DOMExceptiona>. For
|
859 |
| - example, the <a>user agenta> may require the call to be |
860 |
| - <a>triggered by user activationa>, or may limit the rate at |
861 |
| - which a page can call <a>show()a>. |
862 |
| - p> |
863 |
| - <p class="note"> |
864 |
| - During the Candidate Recommendation phase, implementations are |
865 |
| - expected to experiment in this area. Developers using this API |
866 |
| - should investigate and anticipate such experiments and understand |
867 |
| - under what circumstances a "<a>SecurityErrora>" |
868 |
| - <a>DOMExceptiona> might occur. If interoperable behavior |
869 |
| - emerges amongst user agents, then that behavior will be |
870 |
| - standardized here before progressing the specification along the |
871 |
| - W3C Recommendation Track. |
| 863 | + example, the <a>user agenta> may limit the rate at which a page |
| 864 | + can call <a>show()a>, as described in the <a href= |
| 865 | + "#privacy">privacy considerationsa> section. |
872 | 866 | p>
|
873 | 867 | li>
|
874 | 868 | <li>If <var>requestvar>.<a>[[\state]]a> is not "<a>createda>"
|
|
0 commit comments