search

WICG / gesture-delegation

Gesture Delegation API proposal
Other
7 stars 5 forks source link

Does the delegation API need to distinguish between transient user activation vs sticky user activation? #5

Closed mustaqahmed closed 7 years ago

mustaqahmed commented 7 years ago

@domenic raised this question in a separate thread:

On naming, my thinking is that we need two concepts in the proposed new world: "X" and "ever has been X". Something like "browsing context has been user-activated" and "browsing context ever has been user activated".

Do we need the distinction in the delegation API?

Alternatively, is it better to simplify the delegation API by substituting the list of APIs in allowedActivationDelegation by a list of "types of user activations to delegate"? Like "sticky" (for all media-like use cases) or "transient" (for all popup-like use cases) or "both"?

jyasskin commented 7 years ago

Can the transient activation actually be propagated by this kind of API? To know when the transient activation is ... active, the iframe needs to receive a message from the parent, but the postMessage should probably propagate the gesture on its own, without needing the parent to opt in globally.

mustaqahmed commented 7 years ago

Yes, transient activation is currently tracked in Chrome through UserGestureTokens, for which this kind of propagation perhaps doesn't make sense. But I was thinking ahead to our experimental user activation model which proposes to switch the token-based transient activation to a document-state based model, like what Chrome does for the sticky activation (for media playback) today. The goal there is to make the whole user activation model simple enough so that all browsers will be willing to implement.

So, yes, this issue can wait until we have the simple model implemented.

mounirlamouri commented 7 years ago

This proposal is meant to delegate the bit of "browsing context has been user activated" as the two features it is meant to be used with are using this information.