861876 - Windows: preventDefault on touchstart doesn't stop synthetic mouse events and click, AND multiple mousemoves being fired

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P2)

Description

[Patrick H. Lauke]

Attachment: event-listener_prevent-default.html

User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31

Steps to reproduce:

Two issues with touch support on Firefox desktop / Windows 8. See attached test page (a variant of what I used for the recent moz hacks article https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how) on a Win 8 laptop with a touchscreen and tap and swipe around on the button.

The test page logs all events being fired (touchstart, touchmove, touchend, mouseover, mousemove, mouseout, mouseup, mousedown, click, etc) but also has a preventDefault added.


Actual results:

- preventDefault seems to be ignored. it should stop the generation of synthetic mouse events per spec http://www.w3.org/TR/touch-events/#mouse-events and according to the behavior of all other browsers (including, strangely, Firefox/Android, which behaves according to spec)

- regardless of the preventDefault issue, Firefox desktop seems to also fire a mousemove events when moving the finger over the touchscreen. Although the spec does not necessarily forbid this, the way Firefox on desktop behaves is very different from all other browsers (again, including Firefox/Android). Usually, touch takes precedence when moving your finger, firing touchmove events as the finger is moved. no mousemove events are fired. Then, once the movement is finished and the finger is lifted, browsers then fire a single mousemove as part of the synthetic mouse events following a touch (to cater for older scripts that may react to those). So, the sequence in all browsers is something like:

touchstart > [touchmove]+ > touchend > mousemove > mousedown > mouseup > click

Firefox for desktop is the only one that fires continuous mousemove events (and something funky about when mousedown is fired), resulting in something more akin to

touchstart > touchmove > touchmove > touchmove > mousemove > mousedown > mousemove > touchmove > mousemove > touchend > mouseup > click

(the order sometimes varies. for very clean "taps" it's fine, but as soon as you slightly move the finger, this almost haphazard event series fires). Particularly the multiple mousemoves and the mousedown firing while touch events are still being handled throws scripts that rely on the common order of touchevents>delay>synthetic mouse events>click.


Expected results:

- preventDefault on a touch event (touchstart, touchmove - per spec - and touchend - per all other browsers) should...prevent default of synthetic mouse events and click being fired)

- moving a finger on touchscreen should fire the same sequence order and number of events as all other browsers: touchstart > [touchmove]+ > touchend > mousemove > mousedown > mouseup > click (note only a single mousemove, and mousedown only after all touch events)

Comment 1

[Patrick H. Lauke]

the preventDefault issue may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=819102 - but that bug is for ARM Gonk, so possibly a completely different beast?

Comment 2

[Patrick H. Lauke]

incidentally, tried to retest this in Firefox 47.0.1 on Windows 10 on a Surface 3, but can't seem to get any touch events to show up (changing dom.w3c_touch_events.enabled to 2 in about:config seems to have no effect)

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Came across this bug while looking for something else.

(In reply to Patrick H. Lauke from comment #2)
> incidentally, tried to retest this in Firefox 47.0.1 on Windows 10 on a
> Surface 3, but can't seem to get any touch events to show up (changing
> dom.w3c_touch_events.enabled to 2 in about:config seems to have no effect)

Yeah, we only support touch events if APZ is enabled, which in turn depends on e10s being enabled. e10s is starting to roll out progressively to users in 48 onwards. The way to test this in Nightly is by creating a "browser.tabs.remote.force-enable" pref and setting it to true. This forces on e10s, which in theory should not be needed, but for the moment is still needed on touch devices.

On Aurora/Beta/Release, you need to additionally set dom.w3c_touch_events.enabled to 1 or 2 to enable the touch events.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Now that touch events are riding the trains I'm going to call this fixed in 52. Note that e10s still needs to be enabled in 52 to get proper touch events support.

Comment 5

[Chris Mills [:cmills]]

I've looked through our touch events docs, and the preventDefault() way of stopping synthetic mouse events firing has been documented in a few places, but we didn't talk about Fx erroneous behaviour anywhere. I also documented touch events being reenabled by default on Fx52 Windows desktop in another bug.

So...I don't think any more doc changes are needed on this bug. Correct me if I'm wrong ;-)