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 < [email protected]> wrote: > 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. > 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. Chris > On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Dec 1, 2021 at 4:43 PM Stephen Mcgruer < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Contact emails [email protected] >>>>>>>>>> >>>>>>>>>> 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 [email protected]. >>>>>>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>> >>>>> 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4_9hPrmzJ2kw26iBzt09dSscvGY%3DsVNOBGeTQQmQ-7Ug%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-S2epmJXbt5Jo76CMqeKCCRm3dQ5T2KeSyeO%2BaX%2BbPnw%40mail.gmail.com.
