Need a consistent set of events that defines user activation

[mustaqahmed]

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!

[mustaqahmed]

Chromium bug to track this: https://crbug.com/826293

[RByers]

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]

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]

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]

In Chrome, we stopped counting Esc key as a user activation to fix a security bug a while ago.

[Edit: fixed the link above!]

[mustaqahmed]

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.

[annevk]

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.

cc @EdgarChen @johannhof

[domenic]

Agreed, that plan sounds great to me.

[eric-carlson]

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?

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.

[mustaqahmed]

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!