New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 25 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug


Sign in to add a comment
link

Issue 392584: TouchEvent feature detection APIs are available only on devices with a touchscreen at chrome startup time

Reported by rbyers@chromium.org, Jul 9 2014 Project Member

Issue description

We currently enable the TouchEvents API (eg. 'ontouchstart' in window returns true) if and only if we detect a touchscreen on chrome startup.  This approach has a number of drawbacks:

- DevTools can't faithfully emulate touch ( issue 133915 )	
- Unexpected behavior differences - eg. sites work fine on a non-touchscreen laptop but are broken on a touchscreen laptop
- KVM (and other hot-swap) scenarios cannot be supported

In no other place do we avoid exposing an API to the web entirely just because we don't have hardware support for it (eg. chrome android still has mouse events enabled even though they're never fired).

I think it's time to rationalize this by enabling the TouchEvent API all the time.  Unfortunately there are still a lot of websites that disable mouse when they detect a touchscreen (https://docs.google.com/a/chromium.org/document/d/12-HPlSIF7-ISY8TQHtuQ3IqDi-isZVI0Yzv5zwl90VU/edit#heading=h.o2rji2c26f1m) and so will be broken by this.

To help mitigate this I think we should:

1. Fully ship and evangelize the pointer/hover media queries as a rational replacement to changing site design/behavior based on the input devices available ( issue 136119 ).

2. Add a site-compat-hacks mechanism (as proposed by ojan@) to give us a mechanism to grant specific high-profile sites some extra time to fix their bug.  In this case we'd disable touch event support on desktop completely for these origins (although implementing this may be tricky since the Element prototype is shared across all tabs in a renderer).  Details forthcoming.
 

Comment 1 by rbyers@chromium.org, Jul 9 2014

One alternative to experiment with here is rather than disable touch events on such sites, perhaps they should opt-in by default to emulating touch events with the mouse.  We should build an extension that does this and see how badly websites break (eg. some sites disable the mouse but also don't have functioning touch handling code).

Comment 2 Deleted

Comment 3 by rbyers@chromium.org, Jul 21 2014

Blockedon: chromium:115475

Comment 4 by rbyers@chromium.org, Jul 31 2014

Note that we should be able to find sites this is likely to break (i.e. that are already broken on touchscreen laptops) by comparing the number of registered mouse event handlers when the page is loaded with and without touch event support.  I'll run this on a large number of top sites and come up with a list.

Comment 5 by rbyers@chromium.org, Aug 15 2014

Blocking: chromium:404128

Comment 6 by rbyers@chromium.org, Aug 21 2014

Blockedon: chromium:400615

Comment 7 by ojan@chromium.org, Oct 16 2014

Cc: -ojan@chromium.org

Comment 8 by alheur...@gmail.com, Feb 24 2015

There is no shortage of hate for IE Compatibility View and anything that even resembles a path toward the slippery slope of introducing a construct that is similar would be unfortunate (re: #2)

Comment 9 by rbyers@chromium.org, Jul 1 2015

Blockedon: chromium:196799
Summary: TouchEvent API should be enabled consistently (was: Enable TouchEvent API all the time)
Another option (now that we're doing pointer events -  issue 196799 ) is to consider the TouchEvents API deprecated and disable support for it entirely on desktop (but obviously still support it on mobile).  That wouldn't address the devtools issue, and it would be a shame to further fragment the platform, but it might be more pragmatic.

In any case, I think we should wait until we've shipped pointer events ( issue 196799 ) before deciding for sure which way we want to go here.

Comment 10 by rbyers@chromium.org, Nov 14 2015

 Issue 555746  has been merged into this issue.

Comment 11 by nzolghadr@chromium.org, Jan 26 2016

Cc: tkonch...@chromium.org mustaq@chromium.org ajha@chromium.org rbyers@chromium.org
 Issue 373991  has been merged into this issue.

Comment 12 by rbyers@chromium.org, Jan 29 2016

 Issue 578695  has been merged into this issue.

Comment 13 by rbyers@chromium.org, Jan 29 2016

Blocking: chromium:578695

Comment 14 by jainabhi...@chromium.org, Feb 1 2016

Labels: Hotlist-ConOps

Comment 15 by rbyers@chromium.org, Jul 1 2016

 Issue 598072  has been merged into this issue.

Comment 16 by rbyers@chromium.org, Jul 1 2016

Blocking: -578695

Comment 17 by rbyers@chromium.org, Jul 1 2016

Blocking: 578695
Cc: girard@chromium.org
 Issue 578695  has been merged into this issue.

Comment 18 by rbyers@chromium.org, Jul 1 2016

Web developers should see http://www.html5rocks.com/en/mobile/touchandmouse/#toc-mostimp for some guidance around this.

Also the sourceCapabilities.firesTouchEvents API can make it trivial to fix these sorts of website bugs: https://github.com/wicg/InputDeviceCapabilities

Comment 19 by rbyers@chromium.org, Jul 1 2016

Oh and this post is probably the simplest explanation: https://developers.google.com/web/updates/2015/10/inputdevicecapabilities

Comment 20 by rbyers@chromium.org, Nov 24 2016

Summary: TouchEvent API is available only on devices with a touchscreen at chrome startup time (was: TouchEvent API should be enabled consistently)

Comment 21 by splinte...@gmail.com, Nov 25 2016

Worth checking https://github.com/w3c/touch-events/issues/64 as well...would be good to get some definitive info in the spec about what the behavior should be.

Comment 22 by rbyers@chromium.org, Dec 22 2016

Blockedon: 644318
Cc: -abarth@chromium.org sunyunjia@chromium.org
Summary: TouchEvent feature detection APIs are available only on devices with a touchscreen at chrome startup time (was: TouchEvent API is available only on devices with a touchscreen at chrome startup time)
Thanks to sunyunjia@'s hard work in  issue 644318  this is now (IMHO) much more rational.  It's only some legacy APIs (used largely for feature detection) that are controlled by this hack:
 - ontouch* members on window, document, Element
 - document.createTouch, document.createTouchList
 - document.createEvent("TouchEvent")

As a result, sites that rely on touch events without depending on these legacy APIs will behave rationally and consistently starting in Chrome 57.

If that sticks, then I think it's worth considering simplifying this one step further: enable the legacy APIs only on mobile (or via the flag) rather than rely on hardware detection.  That will make the behavior more predictable.  A few sites will probably stop working with touch input on desktop, but a few sites will START working with mouse input on desktops with touchscreens (and we know touchscreen laptop users rely more on their mouse than touchscreen in general).  So I think it may be a reasonable tradeoff (especially since we now have PointerEvents).

If we can succeed in shipping that, then I suspect we could get that behavior codified somehow in the specification (mark all the legacy APIs as deprecated and say that for maximum web compat some user agents do not support the legacy APIs without trying to define "mobile" vs. "desktop") and finally put this issue to rest permanently.  

See discussion at https://lists.w3.org/Archives/Public/public-touchevents/2016Dec/0007.html

Comment 23 by dtapu...@chromium.org, Jan 12 2017

Labels: -Pri-2 Pri-3
Bumping to P3 since sunyunjia's changes are in M57 and we will wait and re-evaluate this issue after that is in a stable release.

Comment 24 by rbyers@chromium.org, Jan 19 2017

Blockedon: 332588

Comment 25 by rbyers@chromium.org, Jan 23 2017

Cc: tdres...@chromium.org adlr@chromium.org
 Issue 677603  has been merged into this issue.

Comment 26 by rbyers@chromium.org, Sep 7 2017

Cc: dtapu...@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
Perhaps time to revisit this now and finally remove the hardware-detection-on-startup hack?  dtapuska WDYT?  Also pinged the spec issue: https://github.com/w3c/touch-events/issues/64#issuecomment-327671775

Comment 27 by dtapu...@chromium.org, Sep 7 2017

Owner: eirage@chromium.org
Status: Assigned (was: Untriaged)
I think ya this might be a good attempt for doing some work in Q4.

Comment 28 by mustaq@chromium.org, Oct 6 2017

Issue 766665 description mentions that Edge may have started enabling TEs on desktop conditionally.  Can we please confirm it?  Do we know why?

Comment 29 by mustaq@chromium.org, Oct 17 2017

Blocking: 557565

Comment 30 by eirage@chromium.org, Oct 19 2017

#28: Checked on Edge 40.15063.647.0, they have similar touch event flag to us, default to "Always off", but can turn on to "only on when a touchscreen is detected"(similar to our auto)

Comment 31 by mustaq@chromium.org, Oct 19 2017

This means we don't have to worry about it (since the default is off).  Thanks for confirming.

Comment 32 by bugdroid1@chromium.org, Dec 22 2017

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6a203c9a33449b29f3d98f925a9b61fdf35c2ee

commit a6a203c9a33449b29f3d98f925a9b61fdf35c2ee
Author: Ella Ge <eirage@chromium.org>
Date: Fri Dec 22 16:12:25 2017

Disable legacy touch event APIs on desktop

In this cl, we make touch-events feature in chrome://flag
default to be disabled.

TouchEvent APIs:
- ontouch* members on window, document, Element
- document.createTouch, document.createTouchList
- document.createEvent("TouchEvent")
will be disabled by default on desktop.

Intent to Deprecate and Remove:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KV6kqDJpYiE

Bug:  392584 
Change-Id: I76716f3c4e529e5143bace95ae1b637b461c2ff5
Reviewed-on: https://chromium-review.googlesource.com/729220
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Commit-Queue: Ella Ge <eirage@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526001}
[modify] https://crrev.com/a6a203c9a33449b29f3d98f925a9b61fdf35c2ee/chrome/browser/about_flags.cc
[modify] https://crrev.com/a6a203c9a33449b29f3d98f925a9b61fdf35c2ee/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/a6a203c9a33449b29f3d98f925a9b61fdf35c2ee/chrome/browser/prefs/chrome_pref_service_unittest.cc
[modify] https://crrev.com/a6a203c9a33449b29f3d98f925a9b61fdf35c2ee/content/browser/renderer_host/render_view_host_impl.cc

Comment 33 by eirage@chromium.org, Dec 24 2017

Labels: M-65
Status: Fixed (was: Assigned)

Comment 34 by mattgaunt@chromium.org, Jan 2 2018

Cc: -mattgaunt@chromium.org

Comment 35 by martin.s...@gmail.com, Jan 11 2018

Hi, just my two cents:  
> #28: Checked on Edge 40.15063.647.0, they have similar touch event flag to us, default to "Always off", but can turn on to "only on when a touchscreen is detected"(similar to our auto)  
  
Microsoft claims in Edge status page that Touch Events are available in Edge on all touch-enabled devices, but on Desktops it's actually "Always Off" by default in Flags for some reason.  
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/touchevents/?q=touch%20events  
I'm not sure if there is bug in the Status page or in the default Flags settings, but it makes sense to me to have Touch Events enabled on touch-enabled desktops/laptops.  
  
Disabling touch events by default on desktops, can and will break many games and interactive websites that were designed as "Mobile-first".

Comment 36 by splinte...@gmail.com, Jan 11 2018

> Disabling touch events by default on desktops, can and will break many games and interactive websites that were designed as "Mobile-first".

As there are still many sites/games that take a very naive "if touch events present, assume it's a touch-only device and just register touch event listeners" approach, keeping touch events on is actually what causes many sites to break, since they then don't work at all with mouse/trackpad or keyboard.

Comment 37 by martin.s...@gmail.com, Jan 11 2018

That's a fair point, but still - when talking about disabling Touch events in Chrome on Windows Desktop devices, what does it include? Touch-enabled laptops? Touchscreen desktops like Surface Studio? 2-in-1 devices like Surface Book? Tablets like Surface Pro? Where to draw the line?  
  
> keeping touch events on is actually what causes many sites to break, since they then don't work at all with mouse/trackpad or keyboard.  
  
With disabled Touch events, such pages won't work now on my Surface Pro because I don't have mouse/trackpad or keyboard, unless I buy the detachable keyboard.  
The only right solution is in my opinion keeping Touch events enabled on touch-enabled devices, or deprecating Touch events altogether in favor for Pointer events.

Comment 38 by splinte...@gmail.com, Jan 11 2018

> or deprecating Touch events altogether in favor for Pointer events

won't happen as long as Apple refuse to even aknowledge Pointer Events' existence

Comment 39 by dtapu...@chromium.org, Jan 11 2018

This isn't about disabling touch events in Chrome on Windows desktop; they certainly still work and fire. 

This is about disabling touch event detection in Chrome on Windows desktop devices. So if you are blinding adding the listeners and doing the right things all is well you continue to get touch events. If you are checking that there is a touchstart listener on the document then it will always return false and will send you down the mouse event path in your code.

Comment 40 by martin.s...@gmail.com, Jan 11 2018

> This isn't about disabling touch events in Chrome on Windows desktop; they certainly still work and fire.  
  
This is even worse than expected. We currently use Touch events in our map app, and PE->TE polyfill in browsers not supporting touch events like Edge. I guess we'd need to change the feature detetcion code again:  
https://github.com/aichi/Touchr/blob/master/js/touchr.js#L19

Comment 41 by eirage@chromium.org, Feb 1 2018

Status: Started (was: Fixed)

Comment 42 by eirage@chromium.org, Feb 2 2018

Blockedon: 804890

Comment 43 by rol...@riesol.cl, Jul 31 2018

What will happen if a desktop device has a touch screen, I know a lot of these, can not use the touch?

Comment 44 by eirage@chromium.org, Aug 1

#43: of cause you can still use touch on a desktop device with touch screen. This is not disabling touch on desktop device, but just make such as "document.ontouchstart" returns false to avoid confusion in touch screen detection. Touch events should still work fine.
You can try this on by turning flag on or off via chrome://flags/#touch-events

Comment 45 by farm...@lawsoncardinals.org, Aug 14

As of this year, we have to set Touch Events API to enabled on ALL our users to get the touch working in Chrome.  We use SMARTBoards from SMART Tech and upon upgrading to Windows 10 1803, Notebook 17.1.1, and Chrome 68.x, this has become an issue.  We didn't have the issue with 1703, Notebook 16, and Chrome 67.x.  So not sure the cause, but not being able to do through GPO or some other is causing us to set this on over a hundred machines.  If a machine has multiple users, each user has to set this.  Chrome doesn't recognize ANY touch without setting Touch Events API to enabled.  Can't click links, stop/start video, etc.

Comment 46 by eirage@chromium.org, Aug 14

#45: Are you talking about not able to click link on all websites or some specific site? This should not affect touch functionality.
And also there should be no difference between 67.x stable and 68.x stable since the change is not in either 67/x or 68.x beta/stable. You can see the chrome://flags setting is still on "Auto". 
I highly suspect what you are experienced is a difference issue, could you tell me more detail about it?

Comment 47 by farm...@lawsoncardinals.org, Aug 14

I can test more tomorrow.   From what I know at this time.  The teachers
couldn't navigate or operate videos on YouTube.  They also couldn't operate
Google Slides.

Once Touch Events was set to Enabled from Automatic, they could operate
videos and controls on YouTube and Google Slides worked, also.

Not completely sure it's the same either, but not sure which bug it would
be.  I found similar issue and this was the recommended bug.

Comment 48 by farm...@lawsoncardinals.org, Aug 15

@46: Doing more testing today, even on some machines where the Touch Events API is Enabled, touch in the Chrome windows isn't registering.  We can click in the address bar, and manipulate those functions, close the window, and touch works in Windows, but I can't do ANYTHING in Chrome link click links, operate Google Slides, etc..  I went to MSN.com and couldn't click links there, either.  If this is related to another bug, I would gladly post there, also.  This is potentially affecting over 100 teachers at this point.

Comment 49 by eirage@chromium.org, Aug 15

It's not related. Please file a new bug for your issue :)

Comment 50 by martinme...@gmail.com, Oct 31

We set up kiosks, which is windows 10 desktops with a touchscreen running chrome. The update of chrome 70 affected all the kiosk we set up. Just adding another device since you only think of a laptop with a touchscreen.

Comment 51 by mustaq@chromium.org, Oct 31

martinmedina.1011@gmail.com: please file a separate bug if Chrome 70 broke your use case.  This bug is unrelated, the commit here appeared back in Chrome 65: https://chromiumdash.appspot.com/commit/a6a203c9a33449b29f3d98f925a9b61fdf35c2ee.

Comment 52 by eirage@chromium.org, Nov 1

#51: this change is actually in M70. We reverted this on M65-69 branches due to embeded map issue( crbug.com/804890 )

#51: This is not going to disable touch completely. Are you able to work around this on your project? See https://www.chromestatus.com/feature/4764225348042752.

Comment 53 by eirage@chromium.org, Nov 12

Labels: -M-65 M-70

Comment 54 by eirage@chromium.org, Nov 12

Status: Fixed (was: Started)

Comment 55 by buddu.sk...@gmail.com, Jan 22

Disabling touch by default causes issue related to mouse move events on touch screens. We use Google Maps API where we use mouse events as touch events since Google Maps API doesn't support touch events.
Check out this sample test to reproduce on Chrome 71.0.3578.98 Windows 10 touch screen. 

http://jsfiddle.net/abidCharlotte49er/f0stvz6m/

Sign in to add a comment