Because of regulatory compliance around credit cards (PCI), the most common way that the Payment Request API will be used is via embedded content (e.g., Stripe in an iframe). In such situations, a merchant's site could contain one or more "Buy" buttons, each of which would need to communicate with the embedded content. For example: ```HTML <iframe allowpaymentrequest src="https://stripe.com/buy_stuff"> <iframe> <button this shirt!</button> <button this car!</button> <script> async function buy(itemDetails){ const iframe = document.querySelector("iframe"); // Make network call.. const available = await doWeHaveItInStockStill(itemDetails); if (available) { iframe.contentWindow.postMessage(itemDetails, location.origin); } } window. processOrderDetails(event){ // if it was all fine, shipping, etc. in data } </script> ``` And then in the iframe, there would be a script like this: ``` window. event => { //... show the payment sheet await paymentRequest.show(); } ``` In order to show the payment sheet browser UI, the iframe must call the PaymentRequest.show() method. However, show() must be "triggered by user activation". In Chrome, the click survives both promise.then()/await and postMessage(). In Firefox, however, calling .show() throws a `SecurityError`, because Firefox doesn't think that .show() was "triggered by user activation". What is the right behavior to expect here?

A bit more background, the current "triggered by user activation" of the .show() method was implemented here: https://bugzilla.mozilla.org/show_bug.cgi?id=1442078

Gecko has several different concepts of "user activation". Some of them survive a trip to the event loop. Some do not. The one used in bug 1442078 does not. In general, we do not want to have "user activation" outlive a direct connection between the action and the response in the user's mind. That can still allow for "fast enough" async things. Fundamentally, we need a better concept of "user activation" in Gecko.

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #2) > Gecko has several different concepts of "user activation". Some of them > survive a trip to the event loop. Some do not. The one used in bug 1442078 > does not. Ok, at least there is something for us to work with. > In general, we do not want to have "user activation" outlive a direct > connection between the action and the response in the user's mind. That can > still allow for "fast enough" async things. > > Fundamentally, we need a better concept of "user activation" in Gecko. Agree. We'll poke around and hopefully we can come up with something that benefits all.

This affects https://www.tappaysdk.com/en/payments/google-pay as well as Stripe. (In reply to Marcos Caceres [:marcosc] from comment #0) > In Chrome, the click survives both promise.then()/await and postMessage(). Note that Chrome hasn't implemented this specific check yet… they only added a use counter: https://bugs.chromium.org/p/chromium/issues/detail?id=825270

From talking to a merchant I learned that one reason for this problem with PaymentRequest is the canMakePayment() method. They are using a generic checkout button to either show a payment request dialog (if supported), otherwise redirect to a traditional form. Since canMakePayment returns a Promise, they can't both wait for its response and call .show() while IsHandlingUserInput is true.

Also busted for async/await, it seems: https://bugzilla.mozilla.org/show_bug.cgi?id=1496656