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

Issue 110332 link

Starred by 7 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Mar 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Touch support breaks some sites when enabled for mouse pointers (was: BMW Car Configuration Page doesn't work)

Project Member Reported by, Jan 15 2012

Issue description

go to

the page loads, but nothing on the page is operational. Can't pick a color, or switch to a different tab (eg, interior). 

Works in Safari.

Chrome 17.0.963.33 beta, OS X 10.7.2
Labels: WebKit-Core OS-All
Status: Untriaged
You can't do nothing on this page because:

* the authors wrote the page to work both for touch-based devices and mouse-bound devices, and use feature detection to switch between either code paths
* when in touch device mode, the page explicitly ignores mouse events and vise versa
* the feature detection code smells for TouchEvent to recognize a touch device
* for some reason, we expose TouchEvent as a valid event

As a result, site switches to touch-device mode, listening to touch events only.
Labels: -OS-Mac
Labels: -Pri-2 Pri-1 Mstone-18 ReleaseBlock-Beta
Status: Assigned

The quirk here is that we DO enable TOUCH_EVENTS, but also add a runtime flag. After this patch, there's no longer a check for a runtime flag.

Adam, can you look into this? People aren't able to buy luxury German automobiles in Chrome without your help.

Comment 4 by, Jan 15 2012

I see.  The site is using document.createEvent("TouchEvent"), which is succeeding, but then we don't implement touch events?
We do on some configurations, and we don't on some others. Ask Rob for more details. 

Comment 6 by, Jan 17 2012

AFAIK, we always support touch events in the Chrome renderer but only on some platforms will the browser be sending touch events to the renderer. While the number of platforms where the browser has touch support will probably increase, the possibility will always remain that there is no touch input device actually connected to the hosting device so the situation here: document.create("TouchEvent") succeeds but no touch events are forthcoming can always happen.

It is not clear to me how we should fix this. Out-reach to the website? Pointer events? Some sort of "gestalt" like scheme for the Web platform?

Comment 7 by, Jan 17 2012

rjkroege: Most devices these days have either a keyboard or a touch screen. For devices without a touch input, document.create("TouchEvent") shouldn't succeed.
This is possibly reasonable. My understanding of the market is that "most" is in the progress of changing. So the solution would require create(...) to  succeed or fail dynamically as can be possible to connect & disconnect touch screens to windows and possibly other devices.

Even then, while a site like this might be be at least usable, it's not an ideal user experience: I plug a mouse into a touch-screen laptop and find that on some sites, I can only use the touch screen and not the mouse too...

thakis and I had an offline discussion and decided that dynamically enabling the touch support in Chrome/WebKit based on the presence or absence of a touch device is the right path forward in the short term.

abarth: am willing to help out. Let me know.
@rjkroege: The fix here should be relatively easy.  Notice that in <> we lost a check for RuntimeEnabledFeatures::touchEnabled() when handling document.createEvent("TouchEvent") when we moved that code to be autogenerated.  We just need to make the code generator smarter and add that check back.
@rjkroege: Are you planning to work on this bug, or should I?
@abarth: I took the "fix here should be relatively easy" as you saying that I didn't need to help. Have plenty of bugs already assigned to me. :-)
Ok.  I'll take care of it.  Thanks!
Patch in commit-queue.
Labels: Merge-Requested
Status: Started

Comment 17 by, Feb 3 2012

Labels: -Merge-Requested Merge-Approved
Status: Fixed
Committed revision 106604.

Comment 19 by, Feb 6 2012

Labels: -Merge-Approved Merge-Merged

Comment 21 by, Feb 24 2012

Labels: -Mstone-18 -Merge-Merged Mstone-17 Merge-Approved
Status: Started

Comment 22 by, Feb 24 2012

 Issue 113307  has been merged into this issue.
Note that even with this 'fix', such sites will be broken on machines with touch and mouse input (i.e. according to some sources, most new Windows 8 machines).  The only correct fix is for sites to register for both mouse and  touch events and be prepared to process both.

That said I agree this change is a good mitigation to lower/postpone the impact of the problem.

Comment 24 by, Mar 2 2012

Labels: -Mstone-17 -Merge-Approved Mstone-19 Merge-Merged
Summary: Touch support breaks some sites when enabled for mouse pointers (was: BMW Car Configuration Page doesn't work)
Status: Fixed
Project Member

Comment 26 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 27 by, Mar 10 2013

Labels: -Area-WebKit -WebKit-Core -Mstone-19 Cr-Content M-19 Cr-Content-Core
Project Member

Comment 28 by, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 29 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Comment 30 by, Jul 24 2013


Sign in to add a comment