search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request-1.1/
Other
482 stars 183 forks source link

[Spec] Relax user activation requirement for show() #1009

Closed nickburris closed 1 year ago

nickburris commented 1 year ago

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: https://github.com/w3c/secure-payment-confirmation/pull/236

Preview | Diff

nickburris commented 1 year ago

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

ianbjacobs commented 1 year ago

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.

marcoscaceres commented 4 months ago

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 commented 4 months ago

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

stephenmcgruer commented 4 months ago

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.