[Bug 26809] IE11 on Win8.1 fires a click event after pointer has moved when element has touch-event: none

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26809

Patrick H. Lauke <redux@splintered.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redux@splintered.co.uk

--- Comment #1 from Patrick H. Lauke <redux@splintered.co.uk> ---
Intuitively, this seems expected behavior to me based on the spec.

Normally (on iOS/Android) in the touch event model, if you move your touch
point too much (there is a tiny bit of wiggle room, a few pixels at most, just
to smooth out interaction for users that don't have super-steady fingers,
particularly on high-dpi devices), the UA assumes that what you're actually
doing is a some sort of scroll/movement/gesture. In this case, no compatibility
events are fired, as these are really sent as fallback to convert "tap"
gestures into mouse events to allow the current and legacy web to work on
touchscreens. In the touch event model 'click' is considered to be a
compatibility event (same as the simulated mouse events), and compatbility
events are not fired unless it's a "clean" tap (without too much movement) - so
it's true that iOS/Android do not fire 'click' in this scenario.

Pointer Events have some key differences. Most notably, click is NOT considered
a mouse compatibility event - it can be fired regardless of whether or not
mouse compat events (mouseover, mouseenter, mouseout, mouseleave, mousemove)
are to be fired (for instance, if there are 2 or more pointers, they can all
end up firing 'click' ... in touch events, only the first touch can generate
mouse compat events, and - if i recall correctly - these are suppressed as soon
as there's more than one touch anyway). But, more relevant to this particular
case, when touch-action:none is set then the UA's default behavior is
overridden. Normally, even with Pointer Events, if you move your touch point
too much (again, there are a few pixels of wiggle room), it is again considered
that you're really doing some gesture or scroll behavior - so the pointer is
cancelled (pointercancel is fired) and it's left up to the UA to handle any
further movement/interaction. This means that no more pointermoves, mouse
compatibility events, or any final 'click' are being fired either. However,
when touch-action:none is in effect, UA behaviors are suppressed, so the UA
does NOT assume the extra movement was part of a scroll or similar - so any
movement results in events being dispatched to your script, including mouse
compat events along the way and a final 'click' when lifting the touch point.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 15 September 2014 15:40:03 UTC