[Spec] Relax user activation requirement for show()

[nickburris]

This gives the user agent the ability to relax the user activation requirement on the PaymentRequest.show() method.

This spec change largely follows the relevant change outlined in Secure Payment Confirmation: w3c/secure-payment-confirmation#236

---

Preview | Diff

[nickburris]

@rsolomakhin, PTAL for a first look! First time in this spec 😄

[rsolomakhin]

Welcome to the spec! :-D

[ianbjacobs]

Discussed today at the WPWG meeting: https://www.w3.org/2023/06/22-wpwg-minutes#t04

There were no objections to merging the pull request.

Issue addressed

[marcoscaceres]

It would have been good to also document and specify the redirect feature... I have concerns this went in without WebKit review because I don't think we support this model (and the redirect without requiring user activation... is that is that thing, like, in HTML?).

[marcoscaceres]

also, please kindly always make us the PR template. Otherwise, we miss tests, and bugs filed on other browser engines.

[stephenmcgruer]

Hey Marcos; apologies for missing on the PR template, and I agree that we could have done better here to get WebKit views. I will push back slightly and note that at time of PR creation, to my knowledge Apple was not a member of the WPWG and so was not engaging on PaymentRequest/etc issues, however we could still have requested a standards position at the very least.

We deliberately wrote the spec change so that it was optional for the user agent to allow, but ack that it may not fully address your concerns. Happy to discuss in a future WPWG meeting!

and the redirect without requiring user activation... is that is that thing, like, in HTML?

I may not understand your question correctly, but one can redirect in HTML without any user interaction or activation. Via either JavaScript or 302 redirects. One generally cannot open pop-ups without user interaction (though I don't think it's actually spec'd - it's about the individual browsers pop-up blocker logic), so it's fair to note that this change is risky in that direction. We did weight that up for Chrome very seriously and implemented some mitigations, but ultimately felt the use-case of redirect from aggregator --> frictionless merchant checkout flow was worth supporting.