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
<https://github.com/WICG/capability-delegation>
Specification
https://wicg.github.io/capability-delegation/spec.html
<https://wicg.github.io/capability-delegation/spec.html>
Design doc
https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing
<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
<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
<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 Windowas
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
<https://github.com/mozilla/standards-positions/issues/565>)
WebKit:No signal
Web developers:Positive
(https://discourse.wicg.io/t/capability-delegation/4821/3
<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.isActiveAPI 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
<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 <https://crbug.com/1130558>
Estimated milestone
M100
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5708770829139968
<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
<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
<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/8cdbbd23-a68a-da2c-690a-7d9af50a5a02%40chromium.org.
