Thanks Yoav, my answers to your questions are inline below. Mustaq
On Wed, Jan 26, 2022 at 10:42 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Thanks for pushing this useful feature! > > On Tuesday, January 25, 2022 at 10:46:12 PM UTC+1 Mustaq Ahmed wrote: > >> Contact emails >> >> mus...@chromium.org, smcgr...@chromium.org >> Explainer >> >> https://github.com/WICG/capability-delegation >> > > Do I understand correctly that this intent is to only ship the "payment" > delegation value and not others? > That's correct: we are shipping only "payment" delegation along with the general framework that makes it possible. To clarify further, allowing the delegation of any other capability (for example, "fullscreen") using this general framework still requires changes in the relevant spec (i.e. the FullScreen spec in our example here), therefore would need its own separate spec discussion and intent process. Specification >> >> https://wicg.github.io/capability-delegation/spec.html >> > > Given the initial positive signals from Mozilla, might be worthwhile to > talk to them about integrating this spec directly into HTML. > Great suggestion, and we have got the same feedback from jyass...@chromium.org too! We will kick off the discussion soon, possibly right after landing two pending PRs to our HTML monkey-patch (#20 <https://github.com/WICG/capability-delegation/pull/20> and #23 <https://github.com/WICG/capability-delegation/pull/23>). > 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. >> >> 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). >> 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). >> RisksInteroperability >> >> 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. >> > > Is it safe to assume that browsers would not require user activation until > this would be in place? Or do they already do that? (In which case, this > doesn't change the status quo) > Currently postMessages don't require user-activation. In a browser that does not support delegation, nothing will change. In a browser that supports it, the user activation requirement kicks in only when the postMessage call has the "delegate: payment" option, so past use-cases (without this additional option) won't change anything. Does it answer your question? > Compatibility >> >> There is no compat risk because this is a new feature. >> External signalsGecko: Positive ( >> https://github.com/mozilla/standards-positions/issues/565)WebKit: No >> signalWeb 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 >> > > Any results/learnings from the experimentation? > Unfortunately our main expected origin-trial partner could not participate during the trial, due to delays on their side. However they are working with us to test the feature locally, and believe that it addresses their use-case. -- 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/CAB0cuO7dV-sMEgorh02Wm4viQ0R8Y0Q3kT4vu-5igO4RB12CYQ%40mail.gmail.com.
