You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need a consistent set of events that defines user activation #3849
This is related to #1903, where we are working on a user activation model. Here I am isolating the discussion on "events that should trigger a user activation" because this looks like a parallel work that can go ahead with or without the model question.
Current Activation section mentions (among other things) a list of activation triggering events. Unfortunately the list doesn't represent the reality. A recent catalog of activation-triggering events in Chrome, Edge, Firefox and Safari shows the big inconsistencies we have today, sometimes even between desktop and mobile versions of the same browser.
We need to fix this.
One challenging point is the possibility that the set of events could be API-specific!
FWIW, I'm convinced by the argument here that in addition to a standardized list of events, we should have some single API to be informed of when frame has been activated (to prevent developers from having to maintain a hard-coded list of events, etc.).
In particular, the use case of starting the background music for a game is a good one - it's reasonable to want to do that as soon as the user has indicated any interaction, without necessarily caring what exact form that interaction comes in (eg. launching a PWA, or pressing a gamepad button which fires no dom events at all).
Sorry, I missed @mustaqahmed's response in the WICG thread on this. Let's discuss this particular issue there in the WICG and come back here with any concrete proposal.
This interop problem remains. I recently wrote some web platform tests that assumed pressing keys (using testdriver) was an activation-triggering event, but that was not correct according to the spec, even though it was true in Chrome.
#6818 by @marcoscaceres is related; he is trying to add keypress and keyup, which at least according to @mustaqahmed's OP is a pretty complicated situation across browsers.
For keyboard events in particular, there is a big question as to what should count. E.g. in WICG/close-watcher#7 (comment) we are discussing whether the Esc key should count as user activation. Consider a user who visits a page, and all they do is press Esc; should that let the page show popups or play unmuted video or enter fullscreen??
Let's explore a way to fix the overall mess here. I am proposing to address the following three sub-problems independently, please let us know your thoughts on each of these (and possibly other) cases.
A. Drop all high-level events
This should be the easiest one I believe: the current list of events include "high-level" events like submit because before User Activation v2, the user activation from a mousedown/keydown was not usable in a submit event-handler. This is no longer the case now, so we can drop all of them.
B. Fine-tune low-level events
The list logically omits touchstart (because a swipe is not a user activation and we can't identify a swipe at touchstart). But why is mousedown also omitted? I vaguely remember Chrome facing compat problems when trying to remove mousedown activation. What about other browsers?
What other low-level events do we need to consider? What about pointerdown?
C. Keyboard event trigger should be key-specific
It seems we reached the consensus that Esc key shouldn't activate the page (right?). Similarly, both Chrome (bug) and Firefox (bug) want to make browser hotkeys like ctrl-W or alt-LeftArrow non-activating. Which other keys fall in the same category? Should del and backspace keys activate or not?
To test your favorite browser's behavior, you can try (or tweak) the "control case" in this repro.
Overall that sounds reasonable to me. Probably any kind of browser accesskey you wouldn't want to count as activation? E.g., command+tab shouldn't result in a popup, it should result in a new browser tab.
The list logically omits touchstart (because a swipe is not a user activation and we can't identify a swipe at touchstart). But why is mousedown also omitted? I vaguely remember Chrome facing compat problems when trying to remove mousedown activation. What about other browsers?
We also found compatibility problems when we tried to remove mousedown activation from WebKit.
Apple's WebKit port also includes touchstart activation, but only for media playback. We also tried to remove this at one point, but there were too many compatibility problems.
This PR addressed A, B and most part of C in my plan above. I realized that my original plan (to independently fix the sub-problems) won't work because removing click (for sub-problem A) would leave a gaping hole around keyboard activation!
Activity
mustaqahmed commentedon Jul 24, 2018
Chromium bug to track this: https://crbug.com/826293
RByers commentedon Oct 22, 2018
FWIW, I'm convinced by the argument here that in addition to a standardized list of events, we should have some single API to be informed of when frame has been activated (to prevent developers from having to maintain a hard-coded list of events, etc.).
In particular, the use case of starting the background music for a game is a good one - it's reasonable to want to do that as soon as the user has indicated any interaction, without necessarily caring what exact form that interaction comes in (eg. launching a PWA, or pressing a gamepad button which fires no dom events at all).
RByers commentedon Oct 23, 2018
Sorry, I missed @mustaqahmed's response in the WICG thread on this. Let's discuss this particular issue there in the WICG and come back here with any concrete proposal.
domenic commentedon Sep 21, 2021
This interop problem remains. I recently wrote some web platform tests that assumed pressing keys (using testdriver) was an activation-triggering event, but that was not correct according to the spec, even though it was true in Chrome.
#6818 by @marcoscaceres is related; he is trying to add keypress and keyup, which at least according to @mustaqahmed's OP is a pretty complicated situation across browsers.
For keyboard events in particular, there is a big question as to what should count. E.g. in WICG/close-watcher#7 (comment) we are discussing whether the Esc key should count as user activation. Consider a user who visits a page, and all they do is press Esc; should that let the page show popups or play unmuted video or enter fullscreen??
mustaqahmed commentedon Sep 22, 2021
In Chrome, we stopped counting
Esckey as a user activation to fix a security bug a while ago.[Edit: fixed the link above!]
mustaqahmed commentedon Oct 1, 2021
Let's explore a way to fix the overall mess here. I am proposing to address the following three sub-problems independently, please let us know your thoughts on each of these (and possibly other) cases.
A. Drop all high-level events
This should be the easiest one I believe: the current list of events include "high-level" events like
submitbecause before User Activation v2, the user activation from amousedown/keydownwas not usable in asubmitevent-handler. This is no longer the case now, so we can drop all of them.B. Fine-tune low-level events
The list logically omits
touchstart(because a swipe is not a user activation and we can't identify a swipe attouchstart). But why ismousedownalso omitted? I vaguely remember Chrome facing compat problems when trying to removemousedownactivation. What about other browsers?What other low-level events do we need to consider? What about
pointerdown?C. Keyboard event trigger should be key-specific
It seems we reached the consensus that
Esckey shouldn't activate the page (right?). Similarly, both Chrome (bug) and Firefox (bug) want to make browser hotkeys likectrl-Woralt-LeftArrownon-activating. Which other keys fall in the same category? Shoulddelandbackspacekeys activate or not?To test your favorite browser's behavior, you can try (or tweak) the "control case" in this repro.
annevk commentedon Oct 12, 2021
Overall that sounds reasonable to me. Probably any kind of browser accesskey you wouldn't want to count as activation? E.g.,
command+tabshouldn't result in a popup, it should result in a new browser tab.cc @EdgarChen @johannhof
domenic commentedon Oct 12, 2021
Agreed, that plan sounds great to me.
eric-carlson commentedon Oct 12, 2021
We also found compatibility problems when we tried to remove
mousedownactivation from WebKit.Apple's WebKit port also includes
touchstartactivation, but only for media playback. We also tried to remove this at one point, but there were too many compatibility problems.mustaqahmed commentedon Oct 20, 2021
I just sent out PR #7248, please take a look.
This PR addressed A, B and most part of C in my plan above. I realized that my original plan (to independently fix the sub-problems) won't work because removing
click(for sub-problem A) would leave a gaping hole around keyboard activation!Add a WPT for pointerevent user activation trigger.
Add a WPT for pointerevent user activation trigger.
12 remaining items
Add a WPT for pointerevent user activation trigger.
Add a WPT for pointerevent user activation trigger.
Add a WPT for pointerevent user activation trigger.
Add a WPT for pointerevent user activation trigger.
Add a WPT for pointerevent user activation trigger.
Revert "Add a WPT for pointerevent user activation trigger."
Add a WPT for pointerevent user activation trigger.
Bug 1741225 [wpt PR 31632] - Add a WPT for pointerevent user activati…
Bug 1741225 [wpt PR 31632] - Add a WPT for pointerevent user activati…
Update the list of activation triggering input events
Update the list of activation triggering input events
Update the list of activation triggering input events
Bug 1739634 [wpt PR 31521] - Add a WPT for pointerevent user activati…
Bug 1740815 [wpt PR 31608] - Revert "Add a WPT for pointerevent user …
Bug 1741225 [wpt PR 31632] - Add a WPT for pointerevent user activati…