[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

--- Comment #5 from Patrick H. Lauke <redux@splintered.co.uk> ---
> This is certainly not true, unless you are on IE11/Win8. Just mousedown on
> yellow box in my test page, move the mouse around and then release it and
> you will see that no alert box pops up, i.e. no click is fired. This is the
> case in every browser that I now except IE11 on Windows 8.1 touch.

Interesting, because I'm seeing this exact behavior in Chrome and Firefox on
Windows. What may be masking the effect is that, as part of the normal browser
behavior, when you click and drag on a link in browsers you generally trigger a
"drag this link" behavior (to save a shortcut to your desktop, for instance).

To counter this, I've slightly modified your code, firing a preventDefault on
mousedown. http://codepen.io/patrickhlauke/pen/FixgC - open this in Chrome or
Firefox, click, drag and release while staying within the yellow box. 'click'
is fired. And this is the behavior that you're seeing in IE11/Win8.1 with
pointer events when touch-action:none.

> Also when I look at the sequence of pointer events in my test page (logged
> in console), I see that no pointercancel is being fired at all. IE fires a 
> pointerup and then a click immediately after pointermove events. It just 
> doesn't care whether pointerup is happening at pointerdown location or far 
> away from it.

Two things: it's not firing a pointercancel as the pointer is not canceled. As
I said in my first response, *normally* you'd get a pointercancel because the
UA is signalling "ok, this isn't just a click...must be a gesture like
scroll...cancel the pointer, I got this". But when you have touch-action:none
you're saying to the UA "disregard any standard behavior handling or
gestures...my JavaScript will handle all interactions". So the pointer is *not*
canceled, and all the relevant event are sent to your script. Again, this is
expected behavior (and matches what happens with the mouse, as per the example
above).

> I just can't understand why dragging an element should trigger a click!

Again, this is exactly what happens for mouse currently in all browsers
(barring UA behavior like "drag the link", or similarly "drag an image", which
need to be suppressed (and most old-school "mouse-draggable" slideshow scripts
do this with preventDefault on mousedown or similar). 

> Every touch-enabled slideshow that has linked slides or links inside 
> slides will break because of this.

Any current touch-enabled slideshows will be coded to react to
touchstart/touchmove/touchend, not pointer events, so breakage should not occur
that often by virtue of them not actually working on IE11/Win8.1 on a
touchscreen device at all. Any newly coded slideshows that do take pointer
events into account will also need to take into account this behavior of
pointer events (that a click is fired even after movement has occurred).

> It just doesn't care whether pointerup is happening at pointerdown
> location or far away from it.

Far away perhaps, but still within the boundaries of the original element where
the pointerdown happened. And again, just as with mouse events.

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

Received on Tuesday, 16 September 2014 08:10:17 UTC