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

Issue 392584 link

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

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

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

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.

 
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)
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.
 Issue 555746  has been merged into this issue.
Cc: tkonch...@chromium.org mustaq@chromium.org ajha@chromium.org rbyers@chromium.org
 Issue 373991  has been merged into this issue.
 Issue 578695  has been merged into this issue.
Blocking: chromium:578695
Labels: Hotlist-ConOps
 Issue 598072  has been merged into this issue.
Blocking: -578695
Blocking: 578695
Cc: girard@chromium.org
 Issue 578695  has been merged into this issue.
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
Oh and this post is probably the simplest explanation: https://developers.google.com/web/updates/2015/10/inputdevicecapabilities
Summary: TouchEvent API is available only on devices with a touchscreen at chrome startup time (was: TouchEvent API should be enabled consistently)
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.
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
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.
Blockedon: 332588
Cc: tdres...@chromium.org adlr@chromium.org
 Issue 677603  has been merged into this issue.
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
Owner: eirage@chromium.org
Status: Assigned (was: Untriaged)
I think ya this might be a good attempt for doing some work in Q4.
Issue 766665 description mentions that Edge may have started enabling TEs on desktop conditionally.  Can we please confirm it?  Do we know why?
Blocking: 557565
#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)
This means we don't have to worry about it (since the default is off).  Thanks for confirming.


Project Member

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

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

Labels: M-65
Status: Fixed (was: Assigned)
Cc: -mattgaunt@chromium.org
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".
> 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.
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.
> or deprecating Touch events altogether in favor for Pointer events

won't happen as long as Apple refuse to even aknowledge Pointer Events' existence
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.
> 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
Status: Started (was: Fixed)
Blockedon: 804890
What will happen if a desktop device has a touch screen, I know a lot of these, can not use the touch?
#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
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.
#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?
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.
@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.
It's not related. Please file a new bug for your issue :)
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.
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.


#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.
Labels: -M-65 M-70
Status: Fixed (was: Started)

Sign in to add a comment