1356695 - Firefox 52 on touch-enabled laptop: touch API present, but no touch events fired

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Patrick H. Lauke]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce:

From version 52, touch events have apparently been reenabled on desktop. However, beyond the API being reported, touch events themselves don't seem to fire.


Actual results:

Testing on a Windows 10/Surface 3 laptop with Firefox 52.0.2 (32-bit) with default about:config (dom.w3c_touch_events_enabled set to 2), I see that the API is correctly reported as being present (https://patrickhlauke.github.io/touch/tests/touch-feature-detect.html shows all green).

When testing actual events, it appears no touch events are being fired (e.g. https://patrickhlauke.github.io/touch/tests/event-listener.html only shows mouse events/click when tapping, https://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-pointer-hud.html only recognises one finger but as a mouse, none of the touch-events-specific demos/tests in https://patrickhlauke.github.io/touch/ work)


Expected results:

Touch events should fire, multi-touch should work (e.g. in the tracker demo)

Comment 1

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

Can you go to about:support and check what it says for Multiprocess Windows?

Comment 2

[Patrick H. Lauke]

Multiprocessor Windows: 0/1 (Disabled by accessibility tools)

I do have NVDA https://www.nvaccess.org/ and aViewer https://www.paciellogroup.com/resources/aviewer/ installed (but not running during my testing)

Comment 3

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

Touch events are only enabled when e10s is enabled, and it seems to be off for you. In releases 51 and earlier touch screens were being detected as accessibility devices and so e10s was off by default. IIRC in 52, on 32-bit builds, we fixed that, so touchscreen devices should have e10s enabled. 53 will extend that support to 64-bit builds. There are also other factors such as actual accessibility tools and add-ons that might cause e10s to be disabled. It's not a great situation but that's how it is. For now if you want to force e10s on to test touch events, you can go to about:config and create a new boolean preference browser.tabs.remote.force-enable, set it to true, and restart the browser.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Kats, but why do we exposed the interface to the dom if it's disabled?  Doesn't that break feature detection?

Comment 5

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

That... is a bug, I guess :/

Comment 6

[Patrick H. Lauke]

For what it's worth, recent Chrome versions expose window.TouchEvent on all devices (even when there's no touchscreen present).

But yes, they only return true for things like "'ontouchstart' in window", "'ontouchend' in document" and other classic "sniff to see if it's a touch/mobile device" if there's an actual touchscreen

(see https://bugs.chromium.org/p/chromium/issues/detail?id=392584 / https://patrickhlauke.github.io/getting-touchy-presentation/#46)

Comment 7

[Patrick H. Lauke]

Confirming that creating the new browser.tabs.remote.force-enable == true in about:config made touch events work as expected in my configuration.

So this bug (beyond the "why aren't they working out of the box for me") is now mostly about not exposing the API (either none of it, or at least not the "'ontouchstart' in window" type detects) in situations where touch is not in fact working/disabled

Comment 8

[Patrick H. Lauke]

(plus of course would be good to get the above info around multiprocessor and having to force it explicitly in certain configurations documented somewhere like MDN)

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Dev-doc-needed for noting e10s dependencies on MDN.

Comment 10

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

I wrote a patch to fix this, it resulted in some test failures because we apparently initialize the touch events before the graphics stack is up and running on marionette tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=eb08876db238a93a5ee524f362b2202bc45e68d5

I have another try push going at https://treeherder.mozilla.org/#/jobs?repo=try&revision=dbbfee930f72c86605ccd85e01b5a8528171e3a2 which should address that problem.

Comment 11

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

Attachment: Part 1 - Don't expose DOM touch APIs if APZ is disabled

Comment 12

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

Attachment: Part 2 - Allow gfxPlatform::AsyncPanZoomEnabled to be called earlier

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

[Tracking Requested - why for this release]:

We should probably uplift this as far as we can given its a web compat issue being noticed by sites.  Maybe too late for 53.0, but maybe it can ride along if there is a point release?

Comment 14

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

(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #13)
> We should probably uplift this as far as we can given its a web compat issue
> being noticed by sites.

Note that it's more of an issue for developers than for sites. The exposure of the DOM touch APIs to web content just means that we support touch events, it doesn't mean that we *need* to send touch events. From the point of view of web content, the current behaviour just means "the device supports touch, but the user isn't using touch" which should be a perfectly valid scenario.

For content authors trying to test their websites with touch, it's more of a bug.

Comment 15

[Ben Kelly [:bkelly, not reviewing]]

Oh, I was under the impression sites were taking an x-vs-y decision based on if touch events were enabled.  Still would be nice to uplift, but maybe not as critical as I thought.

Comment 16

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

(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #15)
> Oh, I was under the impression sites were taking an x-vs-y decision based on
> if touch events were enabled.

Some sites do assume touch and mouse are mutually exclusive. But sites that make such an assumption are broken already, so I wouldn't consider this a webcompat issue.

Comment 17

[Patrick H. Lauke]

Sites that assume "if touch API present, only listen for touch" are indeed already broken by design on multi-input environments.

However, they're even more broken with the current situation in Firefox, because the user can't then get anything to work at all (rather than being at least able to use the touchscreen).

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8858545 [details] [diff] [review]
Part 1 - Don't expose DOM touch APIs if APZ is disabled

ok, this doesn't seem to affect how parent process is handled.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b0e0a29a5caa
Don't expose DOM touch APIs with autodetection if APZ is disabled. r=smaug
https://hg.mozilla.org/integration/mozilla-inbound/rev/fd9fa4e180c6
Ensure gfxPrefs is initialized if gfxPlatform::AsyncPanZoomEnabled is called early in startup. r=milan

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b0e0a29a5caa
https://hg.mozilla.org/mozilla-central/rev/fd9fa4e180c6

Comment 21

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

Comment on attachment 8858545 [details] [diff] [review]
Part 1 - Don't expose DOM touch APIs if APZ is disabled

Approval Request Comment
[Feature/Bug causing the regression]: APZ touch support
[User impact if declined]: for Windows users with touch devices but e10s disabled (due to addons or accessibility or whatever), the browser will report that touch events are supported, but will actually convert the touch events to mouse events. This can result in content author frustration and worse user-observable behaviour on sites that don't handle multiple input types properly.
[Is this code covered by automated tests?]: not particularly
[Has the fix been verified in Nightly?]: not yet
[Needs manual test from QE? If yes, steps to reproduce]: yes. on a windows touch-enabled device, disable e10s. Then open the developer tools console on any page and type "window.TouchEvent". If the result comes back as "undefined" then the bug is fixed.
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not very
[Why is the change risky/not risky?]: The logic is relatively straightforward but it's part of a bigger code block with many codepaths and branches to handle different platforms and environments.
[String changes made/needed]: none

Comment 22

[Gerry Chang [:gchang]]

Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!

Comment 23

[ovidiu boca[:Ovidiu]]

I verified this fix on Windows 8.1 x64 and Windows 10 x64 on Surface Pro 2 using Firefox Nightly 55.0a1(2017-04-18) and I can confirm the fix.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8858545 [details] [diff] [review]
Part 1 - Don't expose DOM touch APIs if APZ is disabled

54 was merged to Beta today.

Comment 25

[Gerry Chang [:gchang]]

Comment on attachment 8858545 [details] [diff] [review]
Part 1 - Don't expose DOM touch APIs if APZ is disabled

Fix a touch event support issue and was verified. Beta54+.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/6073f26ea1db
https://hg.mozilla.org/releases/mozilla-beta/rev/1d567ed51160

Comment 27

[Petruta Horea [:phorea], Desktop QA]

Verified as fixed on Firefox 54 beta 1 on a Microsoft Pro 2 tablet with Win 10 64-bit.

Comment 28

[Chris Mills [:cmills]]

I've added a note about what's going on here to the main touch events page:

https://developer.mozilla.org/en-US/docs/Web/API/Touch_events#Firefox_touch_events_and_multiprocess_(e10s)

Does this explain the situation adequately to you Patty? Happy to work on this further ;-)

Comment 29

[Patrick H. Lauke]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #28)
> I've added a note about what's going on here to the main touch events page:
> 
> https://developer.mozilla.org/en-US/docs/Web/API/
> Touch_events#Firefox_touch_events_and_multiprocess_(e10s)
> 
> Does this explain the situation adequately to you Patty? Happy to work on
> this further ;-)

Minor tweak suggestions (you knew that was coming ;) ):

- at the end of the first para, perhaps spell it out: "This means that even on a touchscreen enabled desktop/laptop, touch events won't be enabled."

- in the second para: "going to about:support and look at" > change look to looking

- third para: "for example to test touch events" arguably, it's not so much the testing, but actually getting the touchscreen to work (with touch events). so i'd reword that as "for example to explicitly reenable touch events support".

Comment 30

[Chris Mills [:cmills]]

(In reply to Patrick H. Lauke from comment #29)
> (In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #28)
> > I've added a note about what's going on here to the main touch events page:
> > 
> > https://developer.mozilla.org/en-US/docs/Web/API/
> > Touch_events#Firefox_touch_events_and_multiprocess_(e10s)
> > 
> > Does this explain the situation adequately to you Patty? Happy to work on
> > this further ;-)
> 
> Minor tweak suggestions (you knew that was coming ;) ):
> 
> - at the end of the first para, perhaps spell it out: "This means that even
> on a touchscreen enabled desktop/laptop, touch events won't be enabled."
> 
> - in the second para: "going to about:support and look at" > change look to
> looking
> 
> - third para: "for example to test touch events" arguably, it's not so much
> the testing, but actually getting the touchscreen to work (with touch
> events). so i'd reword that as "for example to explicitly reenable touch
> events support".

The changes look good, so I've made them. Cheers!