Clarifying the algorithm for feature detection

[michaelwasserman]

Ideally, the spec should provide an example (and clarify the window post message algorithm's monkey-patch to eludicate how a site can detect this feature.

Ideally, the site could call postMessage on its own window with a capability to delegate, without user activation, and check for a NotAllowedError (or similar) to detect the user agent's ability to delegate that capability.

The algorithm may also want to consider clarifying the behavior when the destination doesn't have a supporting feature policy.

[michaelwasserman]

My initial testing seems to indicate that it is not readily possible for sites to feature-detect capability delegation support in advance of attempting to use the feature. I thought calling window.postMessage("", { targetOrigin: window.origin, delegate: "fullscreen" }); raise NotAllowedError (or similar) when specifying a delegation when it's not supported by the UA, but that doesn't seem to be the case. I have a potential idea for supporting feature detection (and more clearly conveying delegated capabilities to targets), which I also added to the feature enhancement design doc:

Maybe: Add a field to MessageEvent indicating what capability was delegated? Perhaps it should convey the capability that was specified for delegation, and whether delegation succeeded or failed (or whether or not the source frame had userActivation (old proposal + chromium idl)), so frames can message (themselves or another target) and feature detect support for delegation, even without transient user activation, and also know when delegation has occurred, other than inferring the attempt from the sender’s message data string.

[michaelwasserman]

@mustaqahmed FYI

[mustaqahmed]

Just tweaked the postMessage algorithm to a add new sub-step in Step 8, which throws an exception with unsupported capability delegation. See the patch.

Do we still need a detection mechanism for the case that the user agent does not know about delegation at all?

[michaelwasserman]

That change is helpful, thanks! It'd be optimal to explicitly signal support for delegation (and specific capabilities), but the latest changes may let sites infer support (with some risk of false-positives).

For example, if attempted delegation of an unsupported feature without transient activation yields a "NotSupportedError" DOMException, while attempted delegation of a supported feature without transient activation yields a "NotAllowedError" DOMException, then the site could reasonably infer that a request to delegate a supported capability with transient activation is likely to succeed. WDYT?

[mustaqahmed]

Alternatively, the current algorithm (specifically Steps 8.1~8.6) allows feature-detection without relying on the user activation state: "delegating a capability X to targetOrigin=*" throws a NotSupportedError if the user agent doesn't support delegating X, otherwise it throws a NotAllowedError.

From a developer's perspective, the utility of "feature-detection" seems to be tied to a specific feature, so the question "whether a browser supports capability delegation" becomes moot without a specific capability X. Say a browser supports the delegation of capability X but does not (yet) support the delegation of Y. In that case, the browser would support every use-case that relies on X AND not on Y.

So I am inclined to close this bug now as "resolved". Wdyt?

[michaelwasserman]

Yes, that seems sufficient, thank you!