The default bug view has changed. See this FAQ.

Disable touch events on Windows for devices that do not support touch input

RESOLVED FIXED in Firefox 18

Status

()

Core
DOM: Events
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: smaug, Assigned: jimm)

Tracking

unspecified
mozilla19
x86
Windows 8
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox18+ verified, firefox19+ verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Bug 726615 broke lots of web pages.
(Assignee)

Comment 1

5 years ago
So basically we're saying we won't support touch events on Windows by default? This doesn't seem like the right solution.

I was thinking we could leave this in for a merge or two to see if sites catch on and fix their handling.
I was thinking we could keep touch events enabled on Nightlies, but not on branches.

Do we know how Chrome deals with this situation?
Summary: Disable touch events on window → Disable touch events on Windows
(Assignee)

Comment 3

5 years ago
(In reply to Olli Pettay [:smaug] from comment #2)
> I was thinking we could keep touch events enabled on Nightlies, but not on
> branches.
> 
> Do we know how Chrome deals with this situation?

Based on some simple chrome testing, it looks like they disable by default and flip the pref when they detect a touch input digitizer. We could add something like that pretty easily.

It would mean web sites that improperly use the presence of the handlers as a method of detecting touch input support would remain broken. At least the behavior would be common for two browsers.

Updated

5 years ago
tracking-firefox18: ? → +

Updated

5 years ago
Assignee: nobody → jmathies
Most compatibility issue are

- Touch event is used to detect iOS/Android (Bug 798935 for foxnews)
- Touch event is used to detect touch screen-based browser (Bug 798804 for bbc, Bug 797143 for apple, Bug 795861 for slideshare and etc).  Web site UI is changed for touch.
- If there is touch event in DOM, web site doesn't handle mouse event. (Bug 799852, Bug 798746 for NAVER and etc)

Of course, all issue occurs on Chrome w/ touch enabled, too.
(Assignee)

Comment 5

5 years ago
> Of course, all issue occurs on Chrome w/ touch enabled, too.

I've only found this to be the case when chrome is running on a touch capable device. Are you seeing the same Makoto?

Comment 6

5 years ago
I can confirm the behavior in Aurora 18a2 - touch events are enabled even though they are not supported by the hardware.

Chrome 22 enables touch events by default on touch supporting Windows 7 and Windows 8 devices (though this wasn't listed in the Changelog (and hard to find in the bug reports) and caught many by surprise). On Desktop, Chrome 22 has touch support disabled.

The issue as Makoto said is that most mobile enabled sites are using this simple feature detection

"ontouchstart" in window

and then attach to touch events only. The problem they try to avoid is that most mobile browsers fire synthetic mouse events after all touch events has passed and if you bind to both, you'll have to deal with additional event handling to avoid false positives.

To be frank, in this situation Microsoft's implementation of PointerEvent is easier to use and works in both platforms without breaking one or the other.
Jimm, are you working on the "detect a touch input digitizer" part, 
or should we just disable the events on Aurora?
(Assignee)

Comment 8

5 years ago
(In reply to Olli Pettay [:smaug] from comment #7)
> Jimm, are you working on the "detect a touch input digitizer" part, 
> or should we just disable the events on Aurora?

Yeah I can work that up.
(Assignee)

Comment 9

5 years ago
(In reply to Bundyo from comment #6)
> and then attach to touch events only. The problem they try to avoid is that
> most mobile browsers fire synthetic mouse events after all touch events has
> passed and if you bind to both, you'll have to deal with additional event
> handling to avoid false positives.

According to the W3C spec this shouldn't happen if content calls preventDefault on the touch event - 

"If the preventDefault method of touchstart or touchmove is called, the user agent should not dispatch any mouse event that would be a consequential result of the the prevented touch event."

> To be frank, in this situation Microsoft's implementation of PointerEvent is
> easier to use and works in both platforms without breaking one or the other.

This spec isn't far enough along for us to implement by default but we are keeping an eye on it.

Comment 10

5 years ago
(In reply to Jim Mathies [:jimm] from comment #9)
> According to the W3C spec this shouldn't happen if content calls
> preventDefault on the touch event - 
> 
> "If the preventDefault method of touchstart or touchmove is called, the user
> agent should not dispatch any mouse event that would be a consequential
> result of the the prevented touch event."

Yes, but this means that we should prevent all touch events in order to avoid the mouse ones and no click events will be fired. One problematic use case can be when you are making a framework and you don't know what the user is going to bind to.
(Assignee)

Comment 11

5 years ago
(In reply to Jim Mathies [:jimm] from comment #8)
> (In reply to Olli Pettay [:smaug] from comment #7)
> > Jimm, are you working on the "detect a touch input digitizer" part, 
> > or should we just disable the events on Aurora?
> 
> Yeah I can work that up.

This is a bit trickier than I anticipated due to the early init of dom class info, which makes the one-time pref query in nsDOMTouchEvent. I was hoping I'd have an early enough call down in widget where the touch detection code is, but it looks like I'm going to be stuck with putting a bit of win centric code in the event class. :/
(Assignee)

Comment 12

5 years ago
Created attachment 671860 [details] [diff] [review]
fix v.1

This should be safe since we don't do shared lib builds for Windows anymore, afaik. Need to confirm this and run the patch through try as well.
We really need to finish migrating that stuff to WebIDL.  :(
(Assignee)

Updated

5 years ago
Attachment #671860 - Flags: review?(benjamin)
(Assignee)

Comment 14

5 years ago
Try build run - https://tbpl.mozilla.org/?noignore=0&tree=Try&rev=0995a8e3eca0

I made one very small change to a comment here as well - "On Windows if there's no default or user pref set we check manually based on device support."

Updated

5 years ago
Blocks: 793631
(Assignee)

Updated

5 years ago
No longer blocks: 793631
Comment on attachment 671860 [details] [diff] [review]
fix v.1

I don't think this is a good way to do the pref. We should either change dom.w3c_touch_events.enabled to be a 3-state pref (enabled/disabled/autodetect) or we should have a separate bool pref (dom.w3c_touch_events.autodetect).

Is this sytem metric "static", or does it change as you connect and disconnect potential touch devices? Might the value change while Windows is booting up and connecting USB devices? Since we only check the value once, I'm worried that we might end up disabling touch when we didn't mean to.
Attachment #671860 - Flags: review?(benjamin) → review-
(Assignee)

Comment 16

5 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> Comment on attachment 671860 [details] [diff] [review]
> fix v.1
> 
> I don't think this is a good way to do the pref. We should either change
> dom.w3c_touch_events.enabled to be a 3-state pref
> (enabled/disabled/autodetect) or we should have a separate bool pref
> (dom.w3c_touch_events.autodetect).

3-state sounds good.


> Is this sytem metric "static", or does it change as you connect and
> disconnect potential touch devices? Might the value change while Windows is
> booting up and connecting USB devices? Since we only check the value once,
> I'm worried that we might end up disabling touch when we didn't mean to.

I'm not sure. I don't think we need to worry about startup issues though. Input device hardware should be fully connected before the browser starts. I suppose if you had some sort of external wacom digitizer it might change while the browser is running, but for the type of hardware we are interested in here it should be static. If this settings does change dynamically for a common hardware use case we have a more wide ranging problem since this value also gets cached by the css rule processor.
OS: Linux → Windows 8
(Assignee)

Comment 17

5 years ago
Created attachment 672821 [details] [diff] [review]
3-state fix v.1
Attachment #671860 - Attachment is obsolete: true
(Assignee)

Comment 18

5 years ago
Comment on attachment 672821 [details] [diff] [review]
3-state fix v.1

try test run:

https://tbpl.mozilla.org/?noignore=0&tree=Try&rev=a8e9ca869438
Attachment #672821 - Flags: review?(benjamin)

Updated

5 years ago
Blocks: 794711
Comment on attachment 672821 [details] [diff] [review]
3-state fix v.1

In the NS_ERROR case, please set sPrefValue = false. I think this could probably be a warning not an error, but I don't think I much care.
Attachment #672821 - Flags: review?(benjamin) → review+
(Assignee)

Comment 20

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/321ee246dc59
https://hg.mozilla.org/mozilla-central/rev/321ee246dc59
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla19

Comment 22

5 years ago
is there a possibility to uplift the fix to firefox 18, since it breaks functionality on quite a few major sites? thanks

Updated

5 years ago
tracking-firefox19: --- → ?
(Assignee)

Comment 23

5 years ago
Comment on attachment 672821 [details] [diff] [review]
3-state fix v.1

We should get this uplifted to aurora as well. Feature was originally enabled in bug 726615.
Attachment #672821 - Flags: approval-mozilla-aurora?

Updated

5 years ago
Attachment #672821 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

5 years ago
tracking-firefox19: ? → +
(Assignee)

Comment 24

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/7d89cb78c6df
(Assignee)

Updated

5 years ago
No longer blocks: 794711
(Assignee)

Updated

5 years ago
Keywords: dev-doc-needed
(Assignee)

Updated

5 years ago
Summary: Disable touch events on Windows → Disable touch events on Windows for devices that do not support touch input

Updated

5 years ago
status-firefox18: --- → fixed
status-firefox19: --- → fixed

Updated

5 years ago
Blocks: 807121
(Assignee)

Updated

4 years ago
No longer blocks: 807121
I tested this on Win7 machines with touch and non-touch screen machines. I didn't notice any problems with the non-touch machines I tried using the latest nightly and aurora.
status-firefox18: fixed → verified
status-firefox19: fixed → verified

Comment 26

4 years ago
Sorry for bumping this old thread but I edited MDN wiki for Touch events to reflect that touch events now have tri-state preference, I am not pro in this and this is my first attempt to help Mozilla community, so you people will not mind it.
Here is updated wiki link: https://developer.mozilla.org/en-US/docs/DOM/Touch_events

So dev-doc-needed whiteboard is not valid I think anymore.
Thanks!
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.