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.
