One initial reaction is that it might be better for the example to use

frame.allowedGestureDelegation.add('media');

rather than

frame.allowedGestureDelegation = 'media';

since using DOMTokenList.add is likely to make sense in more complex cases where the script author doesn't want to stomp on things set by other scripts.

Another initial reaction is that I'm a little worried about how well standardized the related behaviors are. Are there documents that describe Chrome's mitigation behavior well enough for other browsers to implement it compatibly?

I also wonder whether a name less of a mouthful than allowedGestureDelegation could be found...

Gesture is a Chrome-specific term that shouldn't be web exposed. The web equivalent is "user activation" (cf iframe sandbox).

@dbaron I switched to .add(). Our initial name was gesture but it was a bit unclear what this was all about.

@domenic the idea is to expose user activation, not gestures. Happy to rename "Activation Delegation" if the name matters.

Discussed in F2F in Nice.

Thanks for bringing this to our attention! It caused us quite a discussion about auto-play in general :-). The more we discussed this, the more that this "gesture"/"activation" seemed to be a permission-in-disguise. As with permissions, the UA can have a particular policy in place and the Permissions API can reflect that status.

(We'll spin up another issue for the TAG to consider for something like a Permission Observer...)

Given this thinking about auto-play-as-a-permission, we considered this spec. We were pretty united in the desire to see the API shape adopted into Feature Policy. For example, the parent has a permission (policy) applied for the 'autoplay of 'media' [probably blocked by default], and frames are just disallowed until the feature policy is "delegated" using the mechanism there: iframeOb.allow.add('autoplay-media') (which is pretty close to the syntax you were already proposing). [Naming subject to change of course.]

See also: https://github.com/w3ctag/design-reviews/issues/203

(We'll spin up another issue for the TAG to consider for something like a Permission Observer...)

Oh gawd, no more observers please, just use normal events...

@travisleithead this wasn't meant to be a permission in disguise and using Feature Policy was the initial idea. However Ian Clelland, the editor, suggested that we go in this direction.

Taken up at London face-to-face. Thanks @mounirlamouri. We're still concerned about adding this additional new API: not only does it appear to have a lot of semantic similarities with allow (and we'd rather not have two ways of doing the same thing), but we also recognized that this concept is still relatively new, and are cautious about codifying this technique if it turns out that in a year, this approach (with autoplay) doesn't work with users.

@clelland we'd love to have more context on your suggestion to go in the current direction.

My original rationale for making this separate from feature policy was that you might have a situation where:

• the top-level page does not want to delegate any gestures it receives to its subframes
• one of those subframes wants to delegate gestures that it receives to its own children

By using feature policy as the mechanism for gesture delegation, that isn't possible. Once the feature is disabled by the top-level page, there is no way for a subframe to turn that feature on for itself or its own children.

This is, I think, the right behaviour for most features -- for things like fullscreen, geolocation, or camera, you don't want subframes to be able to re-enable them once disabled. For an attribute like this, which is more about defining the relationship between a frame and its immediate children, it makes less sense as a restriction.

Is this work supposed to be superseded by user activation v2? (#295) How does this proposal tie in with the work there?

Closing this as we decided to go another way to resolve the use cases we were targeting.