> 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>. 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.) 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.
