Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation, and we are now following through in the Chrome implementation.
Plan is to deprecate in M98 and remove in M99. We may push the M99 date to M100 based on compat risk; see below.
Interoperability: no risk. Firefox has not shipped PaymentRequest at all, whilst Safari's implementation already requires user activation for calling show(). Compatibility: the main risk. If a website is calling PaymentRequest.show() without a user activation today, it will stop working. If that website doesn't have fallback code to use another payments flow, it may lead to a broken purchase experience for the user. Due to this risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which tracks use of the feature. Although hits on the UseCounter have reduced significantly since 2019*, there is still non-zero usage which is growing slowly over time. We believe the growth to be related to the general increase of web payments, rather than an expanded number of sites. To tackle the remaining usage, we have performed a UKM analysis, and identified the primary remaining site. We are in contact with them, and expect them to roll out a fix in the coming weeks - after which we will revisit the numbers and this thread. * https://chromestatus.com/metrics/feature/timeline/popularity/2398
As we are treating this as a deprecation, we intend to use the issues tab (as per the checklist) to warn developers of the upcoming removal. Once the support is removed, calling show() will throw a SecurityError with a clear error message.
Contact emails
smcg...@chromium.orgSpecification
https://www.w3.org/TR/payment-request/#show-methodSummary
Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation, and we are now following through in the Chrome implementation.
Plan is to deprecate in M98 and remove in M99. We may push the M99 date to M100 based on compat risk; see below.
Blink component
Blink>PaymentsTAG review
N/A - enforcement of feature from an already-reviewed specificationTAG review status
PendingRisks
Interoperability and Compatibility
Interoperability: no risk. Firefox has not shipped PaymentRequest at all, whilst Safari's implementation already requires user activation for calling show(). Compatibility: the main risk. If a website is calling PaymentRequest.show() without a user activation today, it will stop working. If that website doesn't have fallback code to use another payments flow, it may lead to a broken purchase experience for the user. Due to this risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which tracks use of the feature. Although hits on the UseCounter have reduced significantly since 2019*, there is still non-zero usage which is growing slowly over time. We believe the growth to be related to the general increase of web payments, rather than an expanded number of sites. To tackle the remaining usage, we have performed a UKM analysis, and identified the primary remaining site. We are in contact with them, and expect them to roll out a fix in the coming weeks - after which we will revisit the numbers and this thread.
* https://chromestatus.com/metrics/feature/timeline/popularity/2398
Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1445138)
WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=179056)
Web developers: No signals
Other signals:Debuggability
As we are treating this as a deprecation, we intend to use the issues tab (as per the checklist) to warn developers of the upcoming removal. Once the support is removed, calling show() will throw a SecurityError with a clear error message.
Is this feature fully tested by web-platform-tests?
Yes - https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&alignedRequires code in //chrome?
FalseTracking bug
https://crbug.com/825270Estimated milestones
Deprecate in M98, remove in M99 or M100 (compat risk depending).Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5948593429020672Links to previous Intent discussions
Intent to prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/2PhPgk_k9a0/m/alO4yt_HBQAJ
Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ
- This is a bit of a strange case, where we initially believed that we needed Capability Delegation to support deprecating this feature. However, the partner who needed that ability has instead solved their problem in a different way. As such, we believe it safe to require user activation for show() calls without Capability Delegation being available.
This intent message was generated by Chrome Platform Status and hand edited by smcgruer@.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae4RVpVxnjMS8oJ7WE7yOtAiqqa79%3D8v%2ByNf2XhCtHWgg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU3ebwnoKvHPkXhQeSZ2mSfqgW_i_pXJVqEGaFjPJWWKA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-19DXQBytn%2BUChj%3D5p9JrgrhMZYGxVDYgkv262ttDkoA%40mail.gmail.com.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae4RVpVxnjMS8oJ7WE7yOtAiqqa79%3D8v%2ByNf2XhCtHWgg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU3ebwnoKvHPkXhQeSZ2mSfqgW_i_pXJVqEGaFjPJWWKA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae4RVpVxnjMS8oJ7WE7yOtAiqqa79%3D8v%2ByNf2XhCtHWgg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU3ebwnoKvHPkXhQeSZ2mSfqgW_i_pXJVqEGaFjPJWWKA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
I think [1] would be useful for developers but I see two blockers here: first we need to land the Capability Delegation patch in HTML spec as a "reference point" for this idea, then the PR for navigator.userActivation needs to land too.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4_9hPrmzJ2kw26iBzt09dSscvGY%3DsVNOBGeTQQmQ-7Ug%40mail.gmail.com.
LGTM2 for the extension to 102, but comments below. It would be very good to make progress on landing additional spec pieces.On Tue, Feb 15, 2022 at 8:09 AM 'Mustaq Ahmed' via blink-dev <blin...@chromium.org> wrote:I think [1] would be useful for developers but I see two blockers here: first we need to land the Capability Delegation patch in HTML spec as a "reference point" for this idea, then the PR for navigator.userActivation needs to land too.Hi Mustaq,Is there anything blocking integrating the delegation patch into the HTML spec, and landing the PR for userActivation? There seems to be implementer interest from at least Gecko.
On Tue, Feb 15, 2022 at 11:16 AM Chris Harrelson <chri...@chromium.org> wrote:LGTM2 for the extension to 102, but comments below. It would be very good to make progress on landing additional spec pieces.On Tue, Feb 15, 2022 at 8:09 AM 'Mustaq Ahmed' via blink-dev <blin...@chromium.org> wrote:I think [1] would be useful for developers but I see two blockers here: first we need to land the Capability Delegation patch in HTML spec as a "reference point" for this idea, then the PR for navigator.userActivation needs to land too.Hi Mustaq,Is there anything blocking integrating the delegation patch into the HTML spec, and landing the PR for userActivation? There seems to be implementer interest from at least Gecko.- For the Capability Delegation patch, yes we are already working with Gecko and will start working on an HTML PR soon (see its intent thread).- The PR for navigator.userActivation still "needs implementer interest" I think, cc-ing dtapuska@ if I missed something. (Note that this is separate from the "user activation v2" model which is already spec-ed.)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO6LSycEt_gm1VKHP-_VUgo-ri1x3Ux9f9jrzGaZufWr9g%40mail.gmail.com.
LGTM3 to delay.
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MacxQgXZbh5v5x7wniH4zeW46iis_%2B3CtGG56xE3x5cNtQ%40mail.gmail.com.