@@ -839,6 +839,10 @@ <h2>
839839 MUST act as follows:
840840 </ p >
841841 < ol class ="algorithm ">
842+ < li > If the method was not < a > triggered by user activation</ a > , return
843+ a promise rejected with a "< a > SecurityError</ a > " < a > DOMException</ a >
844+ and terminate this algorithm.
845+ </ li >
842846 < li > Let < var > request</ var > be the < a > PaymentRequest</ a > object on
843847 which the method is called.
844848 </ li >
@@ -856,19 +860,9 @@ <h2>
856860 Optionally, if the < a > user agent</ a > wishes to disallow the call
857861 to < a > show()</ a > to protect the user, then return a promise
858862 rejected with a "< a > SecurityError</ a > " < a > DOMException</ a > . For
859- example, the < a > user agent</ a > may require the call to be
860- < a > triggered by user activation</ a > , 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 > SecurityError</ a > "
868- < a > DOMException</ a > 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 agent</ a > may limit the rate at which a page
864+ can call < a > show()</ a > , as described in the < a href =
865+ "#privacy "> privacy considerations</ a > section.
872866 </ p >
873867 </ li >
874868 < li > If < var > request</ var > .< a > [[\state]]</ a > is not "< a > created</ a > "
0 commit comments