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

Issue 152149 link

Starred by 22 users

Issue metadata

Status: Verified
Owner:
Closed: Jan 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Chrome
Pri: 2
Type: Bug

Blocking:
issue 557565



Sign in to add a comment

All touch-event related APIs should exist iff touch support is enabled at runtime

Reported by joern.be...@gmail.com, Sep 25 2012

Issue description

Chrome Version       : 24.0.1276.1
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
   Chrome 21.0.1180.89 m: OK
     Safari 5: OK
  Firefox 4.x: OK
     IE 7/8/9: OK

What steps will reproduce the problem?
1. open up modernizr-test-page for touch detection: http://modernizr.github.com/Modernizr/touch.html
2. wait
3. see

What is the expected result?
- all tests but one should return No if "Emulate touch events" is turned off:
-- typeof TouchEvent != "undefined"

- if "Emulate touch events" is enabled, the following tests can return true:
-- 'ontouchstart' in window
-- typeof TouchEvent != "undefined"
-- "ontouchend" in document

What happens instead?
starting with Chrome 24 the test (typeof Touch == "object") is the only one still returning false - independent of if "Emulate touch events" is on or off


Basically this breaks any responsive design relying on touch events for mobile devices and click events for desktop. In Chrome 21, you could test touch events but since you can no longer detect touch support, this won't work. 

This bug already existed in Chrome 4-5 (according to modernizr...) and was since fixed

My current (ugly) workaround uses UA testing to figure out if the client is mobile or desktop and THEN tests for touch support. 


UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.12 (KHTML, like Gecko) Chrome/24.0.1276.1 Safari/537.12


 
update: since chrome updated itself today to Version 22.0.1229.92 m the bug also exists in the release channel

--> URGENT
breaks popular plugins like iScroll 4
*push*

Comment 3 by Deleted ...@, Jan 2 2013

*push*
Labels: -Area-Undefined Area-WebKit Feature-Touch MStone-26
Owner: rbyers@chromium.org
Status: Assigned
The only one of the tests that's currently true by default on Chrome stable (m23) is 'typeof TouchEvent != undefined'?  I agree this should be consistent with the other checks (like window.ontouchstart).

However, it sounds like you're saying that you expect chrome desktop never to support touch events, is that right?  Chrome desktop has had support for touch events on Windows and ChromeOS since M22.  At the moment (to avoid broadly breaking sites like you describe) touch event support is enabled dynamically at run-time when we detect a touch screen.  So any site that assumes that touch event support implies a mobile device (or lack of mouse support generally) will be broken on Windows/ChromeOS with a touch screen.  Also, mobile devices like blackberry (and to a lesser extent Android) support mice in addition to a touch screen - so it's never really been true that touch event support implies you can ignore mouse events.

Also, I believe you're conflating the concept of "the browser supports touch events" and "the user has a touch screen".  Just because there is currently no touch screen on a device, doesn't mean chrome shouldn't support touch events.  See  issue 159527  for more discussion.  

Obviously we have a long way to go to make it standard practice and easy for websites to support touch events on desktop devices, but with the rise in popularity of touchscreen laptops (eg. with Win8) this is going to be an important area of focus.
Labels: WebKit-ID-96295
Summary: All touch-event related APIs should exist iff touch support is enabled at runtime (was: Touch detection returns false positives [chrome 24+])
Labels: OS-Chrome Feature-Ash-Touch
Cc: paulir...@chromium.org
Status: Started
I verified that the change in https://bugs.webkit.org/show_bug.cgi?id=96295 causes the modernizer touch tests to all return 'No' when there is no touch screen (or when run with --touch-events=disabled), and all return 'Yes' when there is a touch screen (or when run with --touch-events=enabled) - except for 'typeof Touch=="object"' - Touch is a constructor so it's a "function" not an "object".  +paulirish - is this a bug on the modernizer page?
Project Member

Comment 8 by bugdroid1@chromium.org, Jan 4 2013

Labels: -WebKit-ID-96295 WebKit-ID-96295-REOPENED WebKit-Rev-135562
https://bugs.webkit.org/show_bug.cgi?id=96295
http://trac.webkit.org/changeset/135562
Labels: Iteration-73
Project Member

Comment 10 by bugdroid1@chromium.org, Jan 4 2013

Labels: WebKit-Rev-138808
http://trac.webkit.org/changeset/138808
Cc: stuartcox@google.com
> +paulirish - is this a bug on the modernizer page?

Yes. The page was intended to test all possibilities, and I sourced that window.Touch object test somewhere. We can ignore it.

Thanks for disabling the window.Touch global


rbyers, do you know what change enabled all the feature detects to start passing in m24?
> rbyers, do you know what change enabled all the feature detects to start passing in m24?

Ignore that. Chrome/WebKit is operating as expected, only enabling touch events (and their soft detects) when touch screen is present.
> rbyers, do you know what change enabled all the feature detects to start passing in m24?

We did try enabling touch event support by default on Windows and ChromeOS (to handle scenarios like the KVM one) before we realized how many sites would be broken.  See  issue 130525 ,  issue 138195 .  After users reported issues, as a (temporary?) compromise, we settled for checking for a touchscreen on chrome startup, see  issue 159527 .
Status: Fixed
Committed r138843: <http://trac.webkit.org/changeset/138843>
Project Member

Comment 15 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Feature-Touch -MStone-26 -Feature-Ash-Touch Cr-Content Cr-UI-Input-Touch Cr-UI-Shell-Touch M-26
Status: Verified

Comment 17 by laforge@google.com, Mar 15 2013

Labels: -Cr-UI-Input-Touch Cr-UI-Touch

Comment 18 by laforge@google.com, Mar 15 2013

Labels: -Cr-UI-Touch Cr-UI-Input-Touch
Labels: -Cr-UI-Shell-Touch Cr-UI-Input-Touch-Screen Cr-UI-Shell
Labels: -Cr-UI-Input-Touch
Project Member

Comment 21 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink
 Issue 179711  has been merged into this issue.
This still have not fixed in Chrome 30.0.1560.0 canary and Chrome 28.0.1500.71 m stable.

'ontouchstart' in window
'ontouchstart' in document.documentElement
returns false

typeof(window.ontouchstart)
returns "undefined"

It has to return "true" while selected "Emulate touch events" from Chrome Developer tools.
That is a problem specific to how dev tools emulates touch events, see  issue 133915  (it's emulation isn't capable of fully making 'touch support enabled at runtime').  If you force touch events to be fully enabled (with chrome://flags/#touch-events), then you should see what you expect.
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
@rbyers: thanks for taking care of it. will this make it into a final release any time soon?
Forcing touch events to be fully enabled all the time (via chrome://flags/#touch-events) has been in stable for a long time.

Are you looking for something further?  It's certainly still not ideal.
I expect what Paul wrote above:
>  Chrome/WebKit is operating as expected, only enabling touch events (and their soft detects) when touch screen is present.

In reality I do NOT have a touch screen connected to my PC and my Chrome 33.0.1750.154 m still returns true for standard tests like ('ontouchstart' in window) - contrary to what post #23 says. Tested it in this window in the console. Win7/x64
Blocking: 557565

Sign in to add a comment