Intent to Implement: Simple User Activation

Skip to first unread message

Mustaq Ahmed

Oct 11, 2017, 3:02:27 PM10/11/17
to blink-dev, Domenic Denicola

Contact email

The goal is to define a user activation (or "user gesture") behavior that is simple enough for cross-browser implementation while supporting all major use cases.

Browsers limit the use of "abusable" of APIs (e.g. opening popups or vibrating) through user activation.  While this core concept is common for all browsers, details of the exposed behavior vary significantly between the browsers, and even between APIs of a single browser.  For example,

  • popup blocking (which is the oldest use case of user activation) outcome varies significantly between Chrome, Edge, Firefox & Safari, and

  • in Chrome, popup and full-screen blockers behave differently.

The spec for user activation needs attention too: the current spec is minimal, and adding details to it seems impossible without first defining a consistent behavior that covers existing use cases and/or is backed by a few implementations.

To fix this fragmented state of user activation in the Web, we plan to redefine the behavior from the scratch.  More precisely, we want to devise a user activation model that will support all major use cases, yet will be simple enough to motivate all major browsers to implement it.

Design doc

The design aims to enhance/override the current spec:

Not requesting a tag review yet because we need experiments to figure out the shape of a proposed API.

Interoperability risk

We have very little interop risk because major browsers are already different in many ways, see the motivation above.

Firefox: Mixed public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals

Compatibility risk
There is a risk that the simple model will have to change existing behavior a bit, e.g., modifying the popup time-window after a user activity, or disallowing repeated full-screen requests for a single user gesture etc.  The impact should be small because of current inconsistencies between major browsers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Link to entry on the Chrome Platform Status

Requesting approval to ship?

Philip Jägenstedt

Oct 13, 2017, 8:34:00 AM10/13/17
to Mustaq Ahmed, blink-dev, Domenic Denicola
Do you mean to fix as part of this effort before shipping, or is shipping this part of what's required to figure out what the spec should say?

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit

Mustaq Ahmed

Oct 13, 2017, 12:02:04 PM10/13/17
to Philip Jägenstedt, blink-dev, Domenic Denicola
We definitely aim to ultimately fix the spec through this but the exact timing depends on the situation:
- Whenever (though our planned experiments) we have addressed the few open questions we have in our design, we can propose a spec update, or may be just start the discussion.
- If our experiments shows that we won't see significant regressions in Chrome (we have no way to predict it but there is a chance), we can go ahead with an intent to ship.

Does it sound reasonable?

Oct 16, 2017, 7:21:32 AM10/16/17
to blink-dev, Jochen Eisinger
+ jochen
Reply all
Reply to author
0 new messages