I think [1] would be useful for developers but I see two blockers here: first we need to land the Capability Delegation patch <https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation> in HTML spec as a "reference point" for this idea, then the PR for navigator.userActivation <https://github.com/whatwg/html/pull/4009> needs to land too.
On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor <miketa...@chromium.org> wrote: > Thanks for the thoughtful answers! > > LGTM1. I'll trust you to file bugs / feature requests for those 3 items > (and yeah, 3 sounds like a useful, but hard problem to solve). > > On 2/14/22 9:44 AM, Stephen Mcgruer wrote: > > > Is there anything we can learn about their challenges that might apply > to the broader ecosystem? > > A little, though largely it appears to be a bug in either > their application or in Chrome (we're still trying to figure out which!). > Simplifying, the problem is that they seem to be losing the Capability > Delegation between click and (in a different iframe) the call to PR.show(), > and it's quite tricky to debug this in a large async application. I can > think of a few things that might help: > > 1. Adding capability delegation support to navigator.userActivation > <https://github.com/dtapuska/useractivation> would likely be useful, e.g. > exposing an array of capabilities currently active. This would make it much > easier to quickly debug 'do I have a CD right here'. I hope the Capability > Delegation folks might consider adding this! :) > 2. Pausing user activation timeout when code execution in devtools is > paused would be useful. > 3. More generally (and more hand-wavingly), being able to more easily > trace flows through async iframes 'somehow'. Devtools has some support for > this, and it might just be user error that we and the partner are > struggling, but when we're trying to answer questions like "Is it possible > that this event flowed through an intermediary iframe that was created and > destroyed again before this line of code executed", it can be tricky. > > On Mon, 14 Feb 2022 at 09:27, Mike Taylor <miketa...@chromium.org> wrote: > >> Hi Stephen, >> >> Is there anything we can learn about their challenges that might apply to >> the broader ecosystem? >> >> On 2/14/22 9:22 AM, Stephen McGruer wrote: >> >> Hey all, >> >> Unfortunately we've hit a snag in our deprecation; a partner has been >> having trouble integrating this change into their system, and though we are >> engaged in helping them we haven't made much progress yet. >> >> As such, I'm currently requesting that we delay this deprecation *until >> M102*, to give us more time to help solve their problem before we >> require user activation. (I'm not sure how many LGTMs delaying a >> deprecation requires?) >> >> Thanks, >> Stephen >> >> On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote: >> >>> Hey folks, >>> >>> Following up here - we have determined that the remaining uses *do* >>> necessitate >>> making Capability Delegation available for web developers (see our Intent >>> to Experiment >>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ> >>> - >>> unfortunately our partner didn't engage at that time or we would have >>> caught this earlier :(. ) >>> >>> We expect an Intent to Ship to be sent for Capability Delegation 'soon', >>> targeting M100, and so are planning to push this deprecation out to M100 as >>> well to align with that. >>> >>> Thanks, >>> Stephen >>> On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote: >>> >>>> LGTM3 >>>> >>>> On 12/1/21 12:34 PM, Chris Harrelson wrote: >>>> >>>> LGTM2 >>>> >>>> On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> LGTM1 to deprecate in M98 and remove in M99, assuming no surprises >>>>> come up on the usage front. >>>>> >>>>> On Wed, Dec 1, 2021 at 6:31 PM Stephen Mcgruer <smcgr...@chromium.org> >>>>> wrote: >>>>> >>>>>> To be clear; I think we have a good enough shot of that remaining >>>>>> site fixing their code 'soon' (I expect O(weeks)) that we both: >>>>>> >>>>>> 1. Shouldn't do the removal till they have, and >>>>>> 2. Don't need to provide an alternative in the form of capability >>>>>> delegation. >>>>>> >>>>>> But the code change to at least start this deprecation would have to >>>>>> land by December 9th (or we punt for 1.5 months), hence why we're filing >>>>>> this ahead of them fixing their site :). >>>>>> >>>>>> On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer <smcgr...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> > Does the primary remaining site have fallback code, or will it be >>>>>>> broken? >>>>>>> >>>>>>> Yes and no :). It doesn't have automatic fallback for the specific >>>>>>> payment method the user has selected (Google Pay), but the user could >>>>>>> then >>>>>>> select one of the other payment methods that the site supports (either a >>>>>>> credit card flow or I think PayPal IIRC). >>>>>>> >>>>>>> On Wed, 1 Dec 2021 at 11:05, Yoav Weiss <yoavwe...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 1, 2021 at 4:43 PM Stephen Mcgruer < >>>>>>>> smcgr...@chromium.org> wrote: >>>>>>>> >>>>>>>>> Contact emails smcgr...@chromium.org >>>>>>>>> >>>>>>>>> Specification https://www.w3.org/TR/payment-request/#show-method >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> 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>Payments >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> >>>>>>>>> >>>>>>>>> TAG review N/A - enforcement of feature from an already-reviewed >>>>>>>>> specification >>>>>>>>> >>>>>>>>> TAG review status Pending >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> Does the primary remaining site have fallback code, or will it be >>>>>>>> broken? >>>>>>>> >>>>>>>> >>>>>>>>> * >>>>>>>>> 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 >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>> ? Yes - >>>>>>>>> https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&aligned >>>>>>>>> >>>>>>>>> Requires code in //chrome? False >>>>>>>>> >>>>>>>>> Tracking bug https://crbug.com/825270 >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> Deprecate in M98, remove in M99 or M100 (compat risk depending). >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> https://chromestatus.com/feature/5948593429020672 >>>>>>>>> >>>>>>>>> Links 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 >>>>>>>>> <https://www.chromestatus.com/> 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+unsubscr...@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 >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae4RVpVxnjMS8oJ7WE7yOtAiqqa79%3D8v%2ByNf2XhCtHWgg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>> 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+unsubscr...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU3ebwnoKvHPkXhQeSZ2mSfqgW_i_pXJVqEGaFjPJWWKA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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+unsubscr...@chromium.org. >>>> >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-19DXQBytn%2BUChj%3D5p9JrgrhMZYGxVDYgkv262ttDkoA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> >>>> >> > -- 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+unsubscr...@chromium.org. 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.
