On Fri, Jan 28, 2022 at 9:01 AM Stephen Mcgruer <smcgr...@chromium.org> wrote:
> > Am I correct that currently Chromium allows the Payment Request API to > be used unconditionally in iframes? Do you then intend to send another > intent to change the behavior to require activation, after a suitable > period and working with sites to migrate? > > Correct. This is Intent to Deprecate and Remove: Calling > PaymentRequest.show without user activation > <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/xCW746n6XJI/m/rpqi3Ws2EAAJ> > . > LOL. I feel like I might have LGTMed that one. > We had hoped to land them simultaneously (as we have a good relationship > with the primary user that does not currently have user-activation when > calling show()), however our partner is having trouble with their > migration and we may request to push the enforcement (aka the deprecation) > back to M102. (TBD still; I expect to make the request on the deprecation > thread in the next few days.) > SGTM! LGTM3 for this intent (shipping the API). > > On Fri, 28 Jan 2022 at 11:55, Chris Harrelson <chris...@chromium.org> > wrote: > >> I'm a bit confused about the bit regarding transitioning existing sites. >> Am I correct that currently Chromium allows the Payment Request API to be >> used unconditionally in iframes? Do you then intend to send another intent >> to change the behavior to require activation, after a suitable period and >> working with sites to migrate? >> >> Chris >> >> On Thu, Jan 27, 2022 at 11:13 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> LGTM2 % fixing the spec issue. >>> >>> On Thu, Jan 27, 2022 at 9:53 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> Appreciate the replies, Mustaq. >>>> >>>> This seems like a useful addition to the platform, thanks for working >>>> on it. LGTM1. >>>> >>>> On 1/27/22 12:35 PM, Mustaq Ahmed wrote: >>>> >>>> Hi Mike: >>>> >>>> Appreciate your feedback. My answers are inline. >>>> >>>> Mustaq >>>> >>>> >>>> On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> Hi Mustaq, >>>>> >>>>> On 1/25/22 4:45 PM, Mustaq Ahmed wrote: >>>>> >>>>> Contact emails >>>>> >>>>> mus...@chromium.org, smcgr...@chromium.org >>>>> Explainer >>>>> >>>>> https://github.com/WICG/capability-delegation >>>>> Specification >>>>> >>>>> https://wicg.github.io/capability-delegation/spec.html >>>>> Design doc >>>>> >>>>> >>>>> https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing >>>>> Summary >>>>> >>>>> Capability delegation means allowing a frame to relinquish its ability >>>>> to call a restricted API and transfer the ability to another (sub)frame it >>>>> trusts. >>>>> >>>>> Can you expand more on the relinquishing aspect and how regaining the >>>>> capability happens? I can't find any normative text in >>>>> https://wicg.github.io/capability-delegation/spec.html that explains >>>>> how it happens. Do we look for expired timestamps in >>>>> DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else? >>>>> >>>>> (maybe I'm looking in the wrong place!) >>>>> >>>> You got it right: our proposal missed the normative text around the >>>> relinquishing, yikes! I opened this spec issue >>>> <https://github.com/WICG/capability-delegation/issues/24>, we will >>>> send out a PR to fix this when we get a chance. In the meantime here is >>>> what we wanted to mean: access to activation-gated APIs >>>> <https://html.spec.whatwg.org/multipage/interaction.html#user-activation-gated-apis> >>>> is >>>> lost from the sender frame through consumption, and the receiver frame >>>> checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only. >>>> >>>> If an app wants to delegate its ability to call a restricted JS >>>>> capability (e.g. popups, fullscreen, etc) to a known+trusted third-party >>>>> frame, the app would utilize a Capability Delegation API to "transfer" the >>>>> ability to the target frame in a time-constrained manner (unlike static >>>>> mechanisms like <iframe allow> attributes). >>>>> >>>>> What happens if the delegation is refused (or fails) by the browser >>>>> for some reason? As a developer, how do I know that I shouldn't fire off a >>>>> PaymentRequest that's going to fail? Do we signal anything in the message >>>>> event, if not, should we? >>>>> >>>>> (From the PaymentRequest side, I guess I can handle the failure if >>>>> PaymentRequest.show() is rejected.) >>>>> >>>> Yes, just trying PaymentRequest.show() works on the receiver side >>>> today. As we get more use-cases around delegation, we can explore >>>> signaling on the received message event. I would suggest starting a new >>>> issue to discuss this. >>>> >>>> That's fair - I'll file an issue, but I don't consider this to be a >>>> blocking concern. >>>> >>>> >>>> As for error handling on the sender side, we have a few synchronous >>>> failure conditions in our postMessage >>>> <https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation> >>>> algorithm >>>> <https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation> >>>> already, >>>> can easily new ones as needed. However, if you are thinking about an >>>> asynchronous failure (e.g. detected later when the browser decided to run >>>> the posted task), it seems like an existing problem with postMessage unless >>>> we change it to return a Promise >>>> <https://github.com/whatwg/html/issues/3458> (a separate problem). >>>> >>>>> Blink component >>>>> >>>>> Blink>Input >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput> >>>>> TAG review >>>>> >>>>> https://github.com/w3ctag/design-reviews/issues/655 >>>>> TAG review status >>>>> >>>>> Approved subject to minor changes. >>>>> >>>>> (Work in progress, see >>>>> https://github.com/WICG/capability-delegation/pull/23). >>>>> Risks Interoperability >>>>> >>>>> Interop risk here like any new API: new use-cases relying on >>>>> delegation will fail in a browser that hasn't implemented this feature. >>>>> In >>>>> such a browser, the new API (postMessage() call with an additional >>>>> option) will silently get ignored while preserving the legacy behavior. >>>>> More precisely, the postMessage() call will be treated as if it was >>>>> meant to send the message object only, and the delegated capability will >>>>> behave in the target Window as if no delegation has taken place. >>>>> >>>>> >>>>> Compatibility >>>>> >>>>> There is no compat risk because this is a new feature. >>>>> External signals Gecko: Positive ( >>>>> https://github.com/mozilla/standards-positions/issues/565) WebKit: No >>>>> signal Web developers: Positive ( >>>>> https://discourse.wicg.io/t/capability-delegation/4821/3) >>>>> Debuggability >>>>> >>>>> Developers can test the delegated API by calling it from the console >>>>> of postMessage-target Window. Additionally, on the console of the >>>>> sender Window, navigator.userActivation.isActive API can be utilized >>>>> to check the consumption of user activation as a side-effect of >>>>> delegation. >>>>> Ongoing technical constraints >>>>> >>>>> None. >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> Yes >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Work in progress: >>>>> https://chromium-review.googlesource.com/c/chromium/src/+/3413851 >>>>> Flag name >>>>> >>>>> --enable-blink-features=CapabilityDelegationPaymentRequest >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> Tracking bug >>>>> >>>>> https://crbug.com/1130558 >>>>> Estimated milestone >>>>> >>>>> M100 >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://www.chromestatus.com/feature/5708770829139968 >>>>> Links to previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/9CeLYndESPE/m/AhEttheMBQAJ >>>>> >>>>> Intent to Experiment: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/UK0lGnKuAAAJ >>>>> >>>>> >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://www.chromestatus.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+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7vK4UUEzD%3DwJGnAdyTRxgRrmx7AgfoQjCndi91DF2hGA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7vK4UUEzD%3DwJGnAdyTRxgRrmx7AgfoQjCndi91DF2hGA%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/CAL5BFfV8fECzjRrKi-kUraV80jHokb1FYgjPTmZBxLSfoUxx-w%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV8fECzjRrKi-kUraV80jHokb1FYgjPTmZBxLSfoUxx-w%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/CADY3Mae-L9g0W3KSXyXpuuqAgdym3cFAGLk0uicacOpN%3D%3DE85Q%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae-L9g0W3KSXyXpuuqAgdym3cFAGLk0uicacOpN%3D%3DE85Q%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-vyUP31EC11fxdhePwp4_hsd5%2BCbB5xjZ77w4buLP4TQ%40mail.gmail.com.
