1255436 - Touches on Windows 10 + Surface tablet are erroneously generating wheel events

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Simon Sarris]

Attachment: test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

See attachment. This is only an issue on Windows 10 + Surface:

Make a DOM element with mouse and touch event handlers in order to cancel default panning behavior when touching that element. Try touching the element to see if events are successfully generated


Actual results:

Touching the element in a horizontal swiping motion correctly creates mouse move events.

Touching the element in a vertical swiping motion only creates DOMMouseScroll events.


Expected results:

Mouse (or touch) events should have been created instead of DOMMouseScroll events.

Imagine a mapping app where you want to touch and pan in all directions with your screen touches, but also want the mouse scrollwheel to work. That's currently not possible with Firefox.

This works in other browsers, as they do not generate the wheel events. Instead they generate touch or mouse move events that can be canceled.

Comment 1

[Andrew Overholt [:overholt]]

This seems to work for me in nightly, FWIW.

Masayuki, WDYT?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry for the delay to reply.

(FYI: DOMMouseScroll event is a legacy and Gecko specific event, use "wheel" event instead. It's supported by all browsers in the latest version, IIRC. Although, not related to this bug.)

Although, I don't have surface but I have a notebook whose screen is touch aware, I tested with this PC. Both swiping vertically and horizontally, I see only "touchmove" events are generated in the testcase. But if I tested this via RDP, "mousemove" events are also fired at ending a swipe.

I don't see both "wheel" nor "DOMMouseScroll" events on the testcase, though.

I'm not familiar with TouchEvent behavior and I'm not sure who implemented it on Windows.

Jimm or Smaug:

Do you know who is familiar with our touch event implementation? (or are you?)

Comment 3

[Jim Mathies [:jimm]]

The old w3c touch events were implemented a long time ago, I don't remember who implemented them. I think kats was looking at issues related to touch events since he turned them on with apz last fall.

Comment 4

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

So on Nightly, the dom.w3c_touch_events.enabled pref should be set to 2 which enables touch events. Bug 1244402 is on file for tracking any issues that result and getting that to ride the trains. On all other channels (aurora/beta/release) we don't support touch events on Windows, and we will deal with them differently (they get converted to mouse/wheel events, I think, but I'm not sure).

Simon, can you check on a Nightly build to see if there are any outstanding issues with your test case? If not, then we can dupe this to bug 1244402 (or mark it dependent on that).

Comment 5

[Simon Sarris]

Kartikaya, still not working - I checked in 48.0a1 (2016-04-25). I still get mouse move events if I start the touch left to right, and still get wheel events if I start the touch up to down

dom.w3c_touch_events.enabled is set to 2. (I did not change its value)

(Thanks for the FYI Masayuki. Tested wheel also, but no change.)

Comment 6

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

One more question: if you go to about:support in the Nightly, what does it say under Async Pan/Zoom? If it says "None" it might be because APZ/e10s is disabled and that will disable touch events also. If that's the case, go to about:config, add a new boolean pref with the name browser.tabs.remote.force-enable, set it to true, restart the browser, and check again. Thanks!

Comment 7

[Simon Sarris]

Async Pan/Zoom was indeed "None", I added the config property you specified and now it works!

To be totally clear: I was getting mouse and wheel events before, but now I get only touch events.

Thanks very much. Is there anything else I can do here to help?

Comment 8

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

Thanks for checking! At this point there isn't much you can do, we need to fix up some bugs in the touch events code and test it more thoroughly before we can ship it, but once it ships this bug will be fixed as well. Hopefully we'll get that done in the next couple of months or so.

Comment 9

[Andrew Overholt [:overholt]]

"fixlater" because "next couple of months or so"

Comment 10

[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.