Looks like we missed asking for the official position of Webkit. Just sent the request <https://lists.webkit.org/pipermail/webkit-dev/2022-May/032221.html>.
On Fri, Jan 28, 2022 at 12:02 PM Chris Harrelson <chris...@chromium.org> wrote: > > > 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/CAB0cuO7_trW8kJxXh9YU%2BH68fPPmzPQmY%2B7VTfq2QoFah8YcFg%40mail.gmail.com.
