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. 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/CAB0cuO7J_-nbp2-igwfJeYqKjHa-3x8M8T0-b8RcbPmN0TZXPQ%40mail.gmail.com.
