We are working on a proposal to allow a frame to allow delegating a user gesture from an embedder to an embeddee. In other words, to allow a main frame to delegate to an iframe. This API is to answer for some features that start requiring a user gesture on the document in order to be used like the Vibration API or autoplay in some browsers. The intent is to prevent the embeddee to request to run as part of the embedder; we would like to make sure the embedders have the right tools to avoid this situation.
The repository is available here: https://github.com/mounirlamouri/gesture-delegation/blob/master/README.md
The explainer with more details and a concrete proposal is available here: https://github.com/mounirlamouri/gesture-delegation/blob/master/explainer.md
AFAIK Google was planning to significantly simplify the user gesture model by simply having a global flag that is enabled after the first user gesture. Does this proposal assume that model is in use as well? Or is it separate to that?
It is based on that mechanism. We have had discussions internally to maybe have this delegation work with the current model but it’s not sure we would want to do it.
The idea is that the “global” flag would actually be a “document” flag. We call this “document activation”. This API will allow iframes to use the flag from their parents if the parents allowed it.
That sounds good to me. My only thought would be maybe there could be an attribute on the iframe tag to do the same? (Or is that already part of this?)
Going further, there seem to actually be a bunch of permission attributes on iframe: sandbox, allowfullscreen, IIRC feature policy was defining “allow” - maybe this should tie in to something like the existing “allow” attribute rather than adding more piecemeal attributes?
Does this use case interfere with or consider gestures used when enabled for system accessibility?
We initially considered merging that with Feature Policy but the spec editor recommended otherwise. This isn’t quite a permission and because one would need to have the context of “gesture”, it’s not more verbose (ie.
allow="gesture-media gesture-vibrate" vs
I’m not sure what’s your first question about. The idea is for that attribute to live on the iframe tag. That will allow it to propagate down to sub-sub-frames. It would look like
I would expect this to be orthogonal and any accessibility gesture recognised as a gesture for “document activation” would automatically work with the system.
The idea seems pretty cool.
But rather than an attribute called gesture - which I think will make many people ask the questions above about whether it is something about a specific user interaction such as “swipe-left”, I would paint the bikeshed in some colour whose name carries the idea of delegating, or sharing, permission.
As you note, it isn’t a permission in itself, but it is in some ways about sharing them, and potentially opening the security protection they are designed to provide.
FWIW, we are renaming the proposal to “activation” as gesture is indeed a bit too vague. We don’t intend for websites to specify what type of activation would be delegated but activations have a real meaning in the HTML specification.