2.36 KB, patch
|Details | Diff | Splinter Review|
952 bytes, patch
|Details | Diff | Splinter Review|
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)
Can you go to about:support and check what it says for Multiprocess Windows?
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)
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.
Kats, but why do we exposed the interface to the dom if it's disabled? Doesn't that break feature detection?
That... is a bug, I guess :/
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)
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
(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)
Dev-doc-needed for noting e10s dependencies on MDN.
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.
Created attachment 8858545 [details] [diff] [review] Part 1 - Don't expose DOM touch APIs if APZ is disabled
Created attachment 8858546 [details] [diff] [review] Part 2 - Allow gfxPlatform::AsyncPanZoomEnabled to be called earlier
[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?
(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.
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.
(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.
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 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.
Pushed by email@example.com: 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 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
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
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 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 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+.
Verified as fixed on Firefox 54 beta 1 on a Microsoft Pro 2 tablet with Win 10 64-bit.
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 ;-)
(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".
(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!