Can we make user activation consistent between pointer types?

[flackr]

In 6.4.2 Processing Model we define which types of events are activation triggering input event as follows:

An activation triggering input event is any event whose isTrusted attribute is true and whose type is one of:

• keydown, provided the key is neither the Esc key nor a shortcut key reserved by the user agent.
• mousedown.
• pointerdown, provided the event's pointerType is "mouse".
• pointerup, provided the event's pointerType is not "mouse".
• touchend.

The rationale for omitting touchstart (and as a result pointerdown whose pointerType is not "mouse") seems to be to omit swipes, however mousedown (and hence pointerdown of type "mouse") was not omitted due to compat concerns, with concerns even over removing activation on touchstart for media playback.

However, defining a different activation rule for mouse vs other pointer types complicates the situation for developers, especially those who are building on pointer events who now could easily accidentally land code that works with mouse but not touch due to the different activation event. E.g. a pointerdown listener which tries to play a video would only work when triggered with mouse but not touch.

Since there are compat concerns with removing activation on the down event for mouse and even touch, can we change the rules to consider pointerdown an activation triggering input regardless of pointerType (and touchstart)? If we don't want to have activation as a result of a swipe would it be possible to cancel the pointerdown activation when we dispatch a pointercancel event? Alternately we could exclude pointerdown / touchstart when it could lead to a pan (e.g. can't prevent scroll and touch-action does not prevent panning), but that could result in a fair bit of complexity.

@mustaqahmed thoughts?

[Yay295]

I'm not sure what the problem you're facing is. Could you give an example? Changing how an event works is not likely to happen though because it would break too many websites.

[flackr]

I'm not facing a problem myself, just worried about code like:

enterFullscreen.addEventListener('pointerdown', () => {
  fullscreenElement.requestFullscreen();
});

With the current definition, this will work fine when tested with mouse as we have defined that pointerdown triggers activation if the pointerType is 'mouse'. However, it will fail when used with touch or pen because we don't activate until the pointerup event for those input types.

It also sounds like WebKit had compat issues trying to remove activation on touchstart / pointdown with pointerType == 'touch', so I imagine they'd be unlikely to implement the current proposal, and that many sites are relying on touchstart having activation today.

[EdgarChen]

We recently get a bug report for Clipboard API on touch devices, https://bugzilla.mozilla.org/show_bug.cgi?id=1778437.

[mustaqahmed]

Here is my take on this: while mouse and touch fire very similar low-level events, and Pointer Events provides uniform access to those low-level event, the higher level gestures recognized from mouse vs touch vary significantly. Since user activation conceptually captures a higher level user intention, the mouse vs touch difference in user activation is logical.

This idea came up in the discussion around @domenic's post linked above, but let me summarize that in the context of this issue for convenience: Chrome removed user activation trigger from touchstart event to prevent false navigation and popups by an ad subframe when the user happens to start swiping on top of the ad. See Stricter user gestures for touch which shipped on Chrome M56. This doc mentions the side-effect we are discussing here:

... any sensitive operation on touchstart or touchmove will not work

(which maps directly to pointerdown/pointermove in this discussion), and concludes with a developer guidance that "sensitive operations should ideally be performed only inside of click". I agree with this conclusion here even from the perspective of Pointer Events because high-level gestures from mouse and touch are beyond the scope of Pointer Events.

[flackr]

I agree that it's desirable that scrolling does not result in user activation, however, I think the more subtle differences we have between different pointer types the more likely developers make mistakes even following common guidance (e.g. using pointer events).

What do you think about what I suggested above, scoping the user activation on touchstart to only be in cases where it may not become a scroll. This would provide a well lit path for developers who run into this issue by simply adding touch-action: none to their button which invokes an API requiring user activation on pointerdown, and still prevent the degenerate cases where starting a scroll can show a popup.