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

Issue 36415 link

Starred by 39 users

Issue metadata

Status: Fixed
Closed: Nov 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Compat

Sign in to add a comment

Implement touch events API

Project Member Reported by, Feb 22 2010

Issue description

The touch events API is not yet supported under Chromium. The V8 work has
already been merged into mainline WebKit by the Android project. I've
started working on plumbing these events into Chromium.

Comment 1 by, Mar 15 2010

The following revision refers to this bug: 

r41619 | | 2010-03-15 13:00:52 -0700 (Mon, 15 Mar 2010) | 6 lines
Changed paths:

Add support for testing the touch event mechanism to test_shell.

BUG= 36415 

Review URL:

Comment 2 by, Mar 15 2010

The following revision refers to this bug: 

r41620 | | 2010-03-15 13:07:31 -0700 (Mon, 15 Mar 2010) | 6 lines
Changed paths:

Enable the touch events feature.

BUG= 36415 

Review URL:

Comment 3 by, Mar 16 2010

The following revision refers to this bug: 

r41745 | | 2010-03-16 12:21:21 -0700 (Tue, 16 Mar 2010) | 6 lines
Changed paths:

Enable the touch events tests.

BUG= 36415 

Review URL:

Comment 4 by, Mar 17 2010

The following revision refers to this bug: 

r41793 | | 2010-03-16 17:39:53 -0700 (Tue, 16 Mar 2010) | 6 lines
Changed paths:

Mark touch-target as flaky for all platforms.

BUG= 36415 

Review URL:

Comment 5 by, Mar 17 2010

The following revision refers to this bug: 

r41797 | | 2010-03-16 18:09:26 -0700 (Tue, 16 Mar 2010) | 6 lines
Changed paths:

Mark touch-target as CRASH, and basic-single-touch-events as TIMEOUT

BUG= 36415 

Review URL:

Labels: LayoutTests LTTF

Comment 7 by, Mar 19 2010

The following revision refers to this bug: 

r42068 | | 2010-03-18 19:23:23 -0700 (Thu, 18 Mar 2010) | 6 lines
Changed paths:

Un-flag touch tests as flaky on all platforms.

BUG= 38347 ,  36415 

Review URL:

Comment 8 by, Mar 29 2010

Labels: HTML5
Someone complained that chrome claims to support touch events even though they don't work yet (see thread 
"chromium-html5] Touch events supported in Chrome?").

If this isn't fully implemented yet, it shouldn't be exposed to JavaScript.

Comment 10 by, Apr 12 2010

The feature's waiting for platform support before it can be finished (at least under
gtk, I haven't looked at the Windows side of things). However, the problem that
people are reporting isn't, in my opinion, a valid one.

When a page detects the presence of an onclick handler, is it safe to assume that the
user will interact exclusively with a mouse? In fact, if the page can set an onclick
handler does that even prove the existence of a mouse? It simply proves the existence
of the exposed JS plumbing for handling mouse events, but makes no statement about
the presence (or priority, but more on that later) of such hardware.

In the case of the touch event handlers, it's absolutely correct to say that they
don't work in the sense that nothing will currently deliver a touch event based on
user input at this point. It's not, in my opinion, correct to say that the ability to
set a touch event handler indicates that the browser _will_ deliver touch events, or
that the user _wants_ to use touch as the primary mode of interaction with the page
and forego the use of the mouse.

Consider a device with both a touchscreen and mouse device (Lenovo S10-3t, Acer
1420P, HP TouchSmart, Dell XT2, etc.). When a page loads and detects that the browser
can deliver touch events, can the page assume that the user will not use the
mouse/trackpad and will favour the touchscreen? The issue comes down to the fact that
pages are trying to use the presence of a capability (touch events, in this case) to
restrict their UI to what they believe to be the user's primary (and preferred) mode
of interaction, even though the _presence_ of the capability shouldn't indicate a
_preference_ for that capability.

I think that the right thing to do is to have handlers for both mouse and touch
events if you want the user to be able to interact with both, and not bias your UI
towards touch-driven input (which is what the reporters are doing in this thread:
by not setting mouse event handlers when they detect the presence of touch event
This is a re-post from the chomium-discuss mailing list Fri, Apr 9, 2010 at 4:33 PM:


I'm trying to make a better user experience for touch devices, but
find it very hard to find the best practice.

The only way I've found to detect touch capable devices was to check
if the browser supports touch events. But with the most recent Chrome
from the dev channel (5.0.371.0 dev), the touch events seems to be
enabled for all devices. Not only touch screen devices.

Will the touch events continue to be available for non-touch devices,
or is this a bug?

Specifically, I check if the code below throws en error. If it
doesn't, I expect the device to support touch:

Mozilla has a custom CSS3 media query, but I haven't found anything
similar in other browsers: -moz-touch-enabled

Anyone know if chromium/webkit has any plans for a touch-enabled media
query? Or another way to give users of a touch device a better

Gregers Rygg


To be more precise:
I don't think this is a bug, but something that needs to be discussed. Developers
need a way to detect touch-devices to give touch users a better user-experience. Even
if they have a mouse. If you have ever tried using a browser on a touch-device you
know how frustrating it can be. The best solution in my opinion, would be that WebKit
also implemented a media query similar to -moz-touch-enabled.

Does that sound like a reasonable solution? In that case, I can send a feature
request to WebKit.

Please prove me wrong:
gdk: This is all well and dandy in theory, but in practice having these handlers exposed right now causes real 
problems without any benefit since we never send touch events atm. Couldn't you just not expose the touch 
handlers to js for now? See comment 9 :-P
Thanks for considering and fixing this issue. I've enjoyed Touch on Firefox for a
while now. I prefer Chrome but the lack of touch makes it limiting for me. Hopefully
this issue is still alive, shame it did not make the cut for 5.0 :(
Thanks for adding the command-line switch. But why is touch enabled by default in the
stable release? This will break a lot of sites, since detecting for touch events is
(was) the only way to give users with touch devices a better UX. Please consider
fixing this in the stable release!
Labels: Area-Compat-Web

Comment 18 by, Jun 14 2010

Labels: Mstone-X
I would like to know whether it is possible for the browser to treat a touch-down (i.e. not a 'tap' but a finger-down-and-held-there) as the touch counterpart to hover/mouseOver rather than as a 'select' if -webkit-user-select: none CSS is in effect for the element in question.  I've noticed that on iPad Safari, if an image-map AREA has both a mouseOver and a click event, the mouseOver event fires with a 'tap' and the click-event is suppressed. But I'd like to have both touch and tap events (i.e. hover and click) in the touch model when -webkit-user-select:none is in effect. 

Comment 21 by, Dec 26 2010

The expectations for layout test fast/events/touch/touch-target.html are being revised to FAIL TIMEOUT due to differing failure modes on different platforms. See  Issue 67919 .

Comment 22 by, Jan 31 2011

I've got a brand new MacBook and could not believe, that there's not a single browser that is able to deliver touch events to JavaScript fomr the MacBook's touch pad :(

Please implement support for Apple's beautiful touchpad in order to ease the adaption of webapps to mobile platforms like Android or iOS.

   TIA, Wolfgang
Labels: -Area-Compat-Web bulkmove Area-Compat
The layout test issue is fixed in
Note a CSS media query for touch events is tracked in  issue 123062 .
Labels: -Mstone-X Mstone-23
Status: Fixed
I think we can call this done now, right?  Chrome has been shipping with Touch Events support on Windows and ChromeOS for a few releases.
Project Member

Comment 27 by, Mar 10 2013

Labels: -Type-Feature -Area-Internals -Mstone-23 -Area-Compat Type-Compat Cr-Internals M-23

Sign in to add a comment