[Spec] Relax user activation requirement for show() #1009
Conversation
|
@rsolomakhin, PTAL for a first look! First time in this spec 😄 |
|
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. |
|
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?). |
|
also, please kindly always make us the PR template. Otherwise, we miss tests, and bugs filed on other browser engines. |
|
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!
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. |
As per the plan outlined in #1021#issuecomment-2107832273, we have now created the CR Snapshot and published a new CR Draft (https://www.w3.org/TR/payment-request/) that includes restoring the address changes. The only remaining work for that plan is to restore the previous changes that had been made since REC. Changes included: - [Spec] Relax user activation requirement for show() #1009 Additional edits on tops of above changes: - Add note linking to issue #1022 for discussion of user activation relaxing conditions Fixes #1025
As per the plan outlined in #1021#issuecomment-2107832273, we have now created the CR Snapshot and published a new CR Draft (https://www.w3.org/TR/payment-request/) that includes restoring the address changes. The only remaining work for that plan is to restore the previous changes that had been made since REC. Changes included: - [Spec] Relax user activation requirement for show() #1009 Additional edits on tops of above changes: - Add note linking to issue #1022 for discussion of user activation relaxing conditions Fixes #1025
As per the plan outlined in #1021#issuecomment-2107832273, we have now created the CR Snapshot and published a new CR Draft (https://www.w3.org/TR/payment-request/) that includes restoring the address changes. The only remaining work for that plan is to restore the previous changes that had been made since REC. Changes included: - [Spec] Relax user activation requirement for show() #1009 Additional edits on tops of above changes: - Add note linking to issue #1022 for discussion of user activation relaxing conditions Fixes #1025
5 participants
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