Closed Bug 1412485 Opened 2 years ago Closed 9 months ago

Consider removing some parts of touch event APIs on desktop

Categories

(Core :: DOM: Events, enhancement, P2)

enhancement

Tracking

()

VERIFIED FIXED
mozilla67
Tracking Status
relnote-firefox --- -
firefox57 --- unaffected
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- verified

People

(Reporter: stone, Assigned: smaug)

References

Details

(Keywords: dev-doc-complete, parity-chrome, site-compat, Whiteboard: [webcompat])

Attachments

(3 files)

Chrome's going to do it: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/KV6kqDJpYiE/YFM28ZNBBAAJ

For web compatibility of those websites which assume touch = mobile, we should also consider disabling touch event APIs by default. So that those websites handle mouse events when browsing on a desktop with touchscreen supported. This doesn't stop firing touch events for gestures.
Priority: -- → P2
Note that we're proposing just removing the older-style feature detection APIs.  Touch events will actually then work consistently on desktop otherwise (including detection via the most direct expression: 'TouchEvent' in window).

http://mozilla.pettay.fi/moztests/touchmove.html
So looks like no touchevent on either Chrome or Edge. Time to think about removing it.

Flags: webcompat?
Whiteboard: [webcompat]

This touchevent issue also breaks embedded Soundcloud players on touchscreen laptops. You can seek in the player using touch events, but not mouse clicks.

e.g. http://www.openculture.com/2015/10/postage-stamps-from-bhutan-that-double-as-playable-vinyl-records.html

Keywords: parity-chrome
Assignee: nobody → bugs

Chrome hides just parts of the API.

Summary: Consider removing touch event APIs on desktop → Consider removing some parts of touch event APIs on desktop

Current patch. Waiting for tryserver results still (try was closed earlier today). I expect some broken tests: cases when ontouch* is used, but now
addEventListener is needed.

Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.

Keywords: site-compat
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/19d1f6485a13
disable legacy touch APIs on desktop, r=masayuki
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Depends on: 1533413
No longer depends on: 1533413

Verified fixed. The New York Times and Soundcloud sites that I reported as broken on my Windows touchscreen laptop now work correctly in today's 67 Nightly.

Status: RESOLVED → VERIFIED

I also confirmed that https://assessments.michaelhyatt.com/lifescore/assessment/ now works on a Windows touchscreen laptop.

Smaug, can you suggest a release note for beta 67?

Flags: needinfo?(bugs)

Something like
"Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event handlers on desktop with touchscreen to make it less likely that websites treat Firefox as a mobile user agent."

Flags: needinfo?(bugs)
Duplicate of this bug: 1535374

(In reply to Olli Pettay [:smaug] from comment #14)

Something like
"Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event handlers on desktop with touchscreen to make it less likely that websites treat Firefox as a mobile user agent."

Exactly. The principle (as discussed on the referenced public-touchevents thread) is that these are all older-style APIs which have long been used across the web to identify a phone form factor. There's no problem with touch events themselves, just the specific feature-detection pattern sites have come to rely on and make assumptions about. Although it's a little hacky (as web compat concessions always are), this distinction is key to the change we made in Chrome - letting us remove much hackier / less reliable hacks about where touch events are and are not supported.

Note to MDN writers: I've mentioned this in the Fx67 rel notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/67#Removals_6

In terms of other work, you should porbably explain this in more detail somewhere, and update BCD.

Sounds like this is mentioned in the MDN page for 67 not the main user-facing release notes.

https://github.com/mdn/browser-compat-data/pull/4095 is merged, and I've added a paragraph about this here:

https://developer.mozilla.org/en-US/docs/Web/API/Touch_events#Browser_compatibility

I'm marking this as dev-doc-complete, but please let me know if you spot anything wrong or missing here.

You need to log in before you can comment on or make changes to this bug.