User activation: different concepts for different usages

[domenic]

This is forked from blink-dev, where @bzbarsky expresses

Basically, it feels like there already isn't a one-size-fits-all notion of "activation" that is appropriate for all uses, and whatever work happens here should be taking that as a baseline assumption. It's not clear to me whether that's happening.

In response, @mustaqahmed forked off #3849 to address this, asking the question, should we maybe use a different set of events for each situation that uses "activation"? I'm raising this thread because I think @bzbarsky was probably suggesting a broader focus, not just on events, and it'd be good to have a dedicated discussion.

The way I see it, with @mustaqahmed's model (explainer, spec PR, rendered spec preview) we have three concepts of activation already, which he lists as:

• Transient activation consuming APIs
• Transient activation gated APIs
• Sticky activation gated APIs

@bzbarsky, do you think this is enough nuance to capture the different notions of "activation"? If not, do you think adding variants with different sets of events would help, e.g. transient-activation-consuming-but-only-clicks? Or did you have other ideas?

[bzbarsky]

So to be clear, I'm not just talking about the sets of events. In general, it feels like there are the following things to consider:

1. Which events constitute "activation"?
2. Which async operations preserve (or not) "activation"?
3. What sync operations (e.g. time passing) preserve (or not) "activation"?

The three API concepts listed above don't really address those issues; unless I am missing something they merely talk about what APIs are available once "activation" has been achieved and how (or whether) use of those APIs affects whether "activation" is preserved or not. The big question is whether the answers to those three questions are the same across all APIs that need "activation". In the spec proposal they are.

Let me give a few specific examples of things I'm not sure @mustaqahmed's model captures:

• Gecko's popup blocker allows popups based on various events, but the policies for different events are different. For some events you are much more limited in number of popups you can open over a page lifetime. Granted, popup blocking is a really hard fit to all this because of various legacy constraints...

• Gecko has activations that time out even if run to completion has not finished. The spec has this concept in the expiry time of the "transient activation flag", but it's not clear to me whether a single value of expiry time (which is what the spec requires) is appropriate across all APIs, due to large differences in threat model across different activation-requiring APIs and legacy constraints. In particular, we may want a more restrictive timeout on new APIs where we don't have compat concerns than we are willing to ship on existing APIs which might have content written to a longer or nonexistent timeout...

There are also other minor quibbles in terms of the event set, of course. Gecko's concept of activation can be triggered by certain key events; the current spec proposal might capture some of that in its change/submit/reset bits, but that might be too restrictive; unclear. Gecko treats mouse/pointer down/up symmetrically, but the spec requires "up". But those are details; the big question is whether it makes sense to have this event set be uniform across all APIs that depend on "activation".

Anyway, I am not actively involved in this work on the Gecko end right now, so I don't know exactly where things stand in our implementation and what plans, if any, there are for evolving this. @smaug---- or @martinthomson might know who would have that information.

[mustaqahmed]

I understand that our model doesn't fully capture the variations Gecko has between various APIs. The core question here is: how many of such variations do we really need for the Web? We want to define a "small" set of variations that works:

• it's hard to capture too many variations through a simple model, and
• a complicated model would discourage cross-browser implementation.

I believe the variations you mentioned are results of isolated API-specific development, instead of being part of a holistic design from user activation perspective. I have seen the same situation in Chromium: we have many many hacks that were added independently only to make individual APIs functional with user activation.

I just investigated Firefox with the hope of finding a pattern in the variations but I failed. In fact, I have got new questions if we want to justify the underlying model:

• On desktop, it allows 50+ popups with click, 20 with mouseup and none with mousedown. Wondering what makes click less restrictive than mouseup.
• On mobile (tested with touch emulation), it allows 50+ popups with mouseup and touchend. Is it because popups are less abusive on mobile vs desktop? If so, a consistent limit of 20 should still work, no?
• On mobile, a long press allows vibration but no popups, while a click allows 50+ popups. From long press perspective, why is vibration considered less abusive than popups? From popup perspective, it also means a long press is a "weaker" user activation than a click. Why?

The Web is currently broken in terms of user activation interop. In #1903, we are trying to fix this through a simple design, because:

• a simple design would possibly motivate cross-browser implementation, and
• one such design seems to be working in Chromium.

[mustaqahmed]

When I looked back at this discussion yesterday after a break, it seems to me that popup blocker is the most significant source for the variations observed. While today popup blocker is fused to (or inseparable from) user activation in perhaps most browsers, it doesn't have to remain so forever.

To be precise, if we define a functional relationship between user activation state and popup blocker as follows, we can address the core concern here in an incremental way:

• popup_blocker = f(user_activation_state, legacy_constraints, other_states)

In other words, popup blocker can rely on and affect user activation state in a limited manner, but the observable behavior of popup blocker can still vary with, say, input event.

Note that this argument applies to any user-activation-gated API, hence redefining user activation state doesn't necessarily mean redefining all dependent APIs in one shot. Instead, other APIs can catch up with a redefined user activation state by gradually getting rid of legacy constraints and other states if necessary. However, I don't believe anything except the popup blocker will need it.

From this perspective, it seems fair to say that user-activation-gated APIs can affect user activation state in only a few limited ways (e.g. as proposed in #1903). So we can still have a single concept for user activation state that covers all use cases.

@bzbarsky: Does it look like a reasonable way forward?

@domenic: Do you see any way the proposed spec can mention this? I guess the section on API classification should be rewritten?

[domenic]

To fit additional pop-up blocking constraints into the spec, you'd modify the pop-up blocking section, i.e. https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name to allow additional user-agent specific leeway in when to popup-block. Something like modifying

If the algorithm is not triggered by user activation and the user agent has been configured to not show popups (i.e. the user agent has a "popup blocker" enabled)

to

If the user agent has been configured to not show popups (i.e. the user agent has a "popup blocker" enabled), and either the algorithm is not triggered by user activation or the user agent has additional implementation-defined heuristics classifying this popup as worthy of blocking

This would be sad for interop, but what I'm hearing from @bzbarsky is that this is a place where, in his view, interop needs to take a back seat to product decisions. I'm not sure I agree, and it'd be interesting to hear if other implementers feel the same way... but that's one path, if we need to do that.