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 29 users
Status: Fixed
Closed: Aug 8
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 584367

Sign in to add a comment
DevTools: DOM0 ontouch* handlers do not work with the "Emulate touch events" mode even after reload
Project Member Reported by, Jun 21 2012 Back to list
Chrome Version       : 20.0.1132.27
OS Version: 
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

What steps will reproduce the problem?
The following code does not work:

<!DOCTYPE html>
<html lang="en">
    <style type="text/css">
            position: absolute;
            width: 50px;
            height: 20px;
            background-color: red;
            top: 50%;
            left: 20px;             
    <script type="text/javascript">
        function init()
            main_div = document.getElementById("main_div");             
            main_div.ontouchstart = function() 
<body onload="init()">
        <p id="x">hello</p>
        <p id="y"></p>
    <div id="main_div">

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.27 Safari/536.11

Reported at

This is a V8-related issue. We need Anton or someone he can point to ;) to pitch in.
Comment 2 by, Jun 25 2012
Erik is probably the best guy to talk to, cc'ing him.
Comment 3 by, Jun 25 2012
Does this work in Safari? (WebKit nightly)
No, it doesn't either. But I remember antonm@ tell me things about different event callbacks defined either on prototypes or proper objects (and that those should be unified), and this concerned touch events in particular. I'm seeing that a "onmousedown" listener is added to a V8Node (seemingly, through "addEventListenerCallback") but a respective "ontouchstart" listener is not added. 

Does any of you know the difference between the two?
@arv: I've recollected my previous investigation results. The "ontouchstart" property is marked as [NotEnumerable,Conditional=TOUCH_EVENTS,V8EnabledAtRuntime] in Element.idl. Consequently, it does not get into the V8Element template unless touch is enabled in RuntimeEnabledFeatures:

    if (RuntimeEnabledFeatures::ontouchstartEnabled()) {
        static const BatchedAttribute attrData =\
        // Attribute 'ontouchstart' (Type: 'attribute' ExtAttr: 'V8EnabledAtRuntime NotEnumerable Conditional')
        {"ontouchstart", ElementV8Internal::ontouchstartAttrGetter, ElementV8Internal::ontouchstartAttrSetter, 0 /* no data */, static_cast<v8::AccessControl>(v8::DEFAULT), static_cast<v8::PropertyAttribute>(v8::None | v8::DontEnum), 0 /* on instance */};
        configureAttribute(instance, proto, attrData);


Do you think there is a way to work around this unfortunate approach? I can enable the respective runtime feature when entering the touch emulation mode if that helps the issue.
Comment 6 by, Jun 26 2012
Ouch! Yeah, we would have to enable the feature when entering the emulation mode. If we didn't there might be other code paths that don't work correctly.
According to yurys@, the V8Element template is cached per-isolate, which is a lot worse (in our case) than per-context. Since explicitly made the respective listeners presence depend on the runtime touch capability (and its effect covering an entire isolate, so page reloads do not help), I tend to close this issue as WontFix.

Pavel, what do you think?
Comment 8 by, Jun 27 2012
There are other ways to achieve what we want here. If our goal is to allow developers to test touch we can get away with some deficiencies. For example we could capture the event on the document and check the target and its ancestors and do our own event dispatch. I believe that that would be good enough for testing this.
@arv: do you imply capturing the event in V8Document.cpp regardless of the runtime feature state? Or something else?
 Issue 168396  has been merged into this issue.
 Issue 168396  has been merged into this issue.
Comment 12 by, Jan 31 2013
This bug should really be fixed. It's quite misleading to have ('ontouchstart' in window) return true. I didn't have a device immediately to verify, and not having used ontouchstart before, I was concerned that Chrome in general does not support ontouchstart on elements.
Project Member Comment 13 by, Mar 10 2013
Labels: -Area-WebKit -Feature-DevTools Cr-Platform-DevTools Cr-Content
Project Member Comment 14 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
 Issue 237093  has been merged into this issue.
 Issue 252373  has been merged into this issue.
 Issue 252373  has been merged into this issue.
 Issue 252373  has been merged into this issue.
Workaround: specify the "--touch-events=enabled" (no quotes) command line flag when starting Chrome.

The drawback is that all DOM object will have the ontouch* listeners set to null from the outset and, consequently, will pass tests like ("ontouchstart" in document).

Thanks to rbyers@ for the hint.
NP.  Note that we consider it a bug when sites rely on tests like "'ontouchstart' in document" to determine whether or not a touch screen is present.  Just because the browser supports touch events, that doesn't mean there is necessarily currently a touchscreen attached (eg. on windows a touchscreen connected via a KVM can come and go throughout the life of a page).  Some day we'd like to make --touch-events=enabled the default.  

Chrome has the 'pointer: coarse' media query for actually testing for the presence of a touchscreen.
Labels: Cr-UI-Input-Touch-Screen
@rbyers: Any ETA for making --touch-events=enabled the default? Is this blocked on something?
Sadly it's unlikely to happen any time soon.  It's blocked on the fact that many websites have code like:
 if (window.ontouchstart)
   listen to touch events
   listen to mouse events

And so enabling touch events often disables support for the mouse!  As touchscreen laptops become more popular (and as we continue to evangalize this problem) I suspect it'll become less of an issue.  But it's bad enough that I'd guess it's going to be at least a year before we can seriously try turning it on by default again... 
Fair point. I believe Paul (cc'ed) can help us promoting the right ways of touch device detection...
Yep, me, Chris, Paul and Matt are beating on this drum (eg. it was one of the central messages of my Google I/O talk, and our HTML5Rocks article).

But we should ideally have some plan for this bug in the interim.  Eg. could we give devtools some way to restart the renderer with this flag enabled?  Or maybe we can figure out some way to dynamically add these properties without restarting V8?
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
This would return "false"
   !!('ontouchstart' in d.createElement('a'))
   'ontouchstart' in d.documentElement
and this returns "true"
   'ontouchstart' in window
while enabled "Emulate touch events" in Developer tools.

The correct result for all that must return "true".
Blockedon: chromium:196283
Giving DevTools a way to enable blink touch events support is tracked in  issue 196283 .  Once that's done, this bug should either fall out naturally or be trivial.
Labels: -OS-Linux -Pri-2 -Cr-Blink OS-All Pri-1 Cr-Blink-Input Hotlist-Input-Dev M-37
Summary: DevTools: DOM0 ontouch* handlers do not work with the "Emulate touch events" mode even after reload (was: DevTools: DOM0 ontouch* handlers do not work with the "Emulate touch events" mode)
Let's focus this bug on the simpler case of making this all work after a reload.  A reload is typically necessary for mobile emulation anyway - eg. to get the server to serve the right content based on the UA.
We appear to be doing something to make 'ontouchstart' in window (and document) be true after a reload.  pfeldman says he suspects that we're injecting dummy properties to fool detection (but since they're fake they still don't work for event dispatch).  We think that on reload we should be able to throw away the entire V8 isolate and recreate it with the correct RuntimeEnabledFeatures.  We can't think of any fundamental reason this should be hard - let's try to get this done for M37.  Pavel and I will continue to investigate.

Note that devtools calls RuntimeEnabledFeatures::setTouchEnabled in InspectorPageAgent::updateTouchEventEmulationInPage.  We probably just need to make sure this happens early enough on reload, and that afterwards we're forcing the V8 isolate to be recreated (and then also remove the injection of these dummy properties).  I don't have the context to know what exactly is required here but I can help figure it out... 
 Issue 196283  has been merged into this issue.
Blockedon: -chromium:196283
I should add that I talked briefly with jochen and he pointed out that since the window object is per-isolate and we re-use an isolate for multiple tabs we can't just restart the isolate without affecting other tabs.

Pavel mentioned we could always swap out the renderer, creating a completely new one (with new settings) if needed.  I think that's the direction we'd need to head here.  pfeldman@ how do we proceed with this?

There would still be some edge case issues - like what if while doing touch emulation you click on a link that opens a new tab same-origin and so must share a renderer?  That new tab will also have touch events enabled even though devtools isn't open for it (and so it's actually emulating touch).  Personally I think this is completely fine (ideally we'd enable touch events all the time), but could be a little surprising in edge cases. 
Another corner case is - if we have two cross-scripting pages (i.e. one of them was'ed), enable touch for one of them and swap out the renderer - scripting will die.
Labels: -M-37 MovedFrom-37 M-38
Moving all non essential bugs to the next Milestone.
Labels: -MovedFrom-37 -M-38
Comment 39 by Deleted ...@, Oct 26 2014
This bug have not been fixed in V:38.0.2125.104 yet?Here is the situation i found.
After shutdown the Emulator type "ontouchstart" in document in console it return with true. And it helpless to refresh the page, you must open another doc window to fix it.
@lizouzt: I can't repro the issue you describe in 38.0.2125.104 - ontouchstart goes away if you disable touch emulation and reload the page.
just tried in 40.0.2201.2 canary:
('ontouchstart' in document) always returns true - no matter what the emulation is set to.
@Joern.Berkefeld: this is actually a correct behavior - "ontouchstart" should always be present. Unfortunately, we can't do this everywhere since some developers still rely on this check. In your case, Chrome decided that your hardware supports touch and added "ontouchstart".
@dgozman: If Chrome also decides to pay for the hardware upgrade I'm happy to accept that. Until then, touching my screen only results in fingerprints no matter how hard I try ;-)
Comment 44 Deleted
Comment 45 Deleted
Here are my steps to reproduce touch persisting on Version 47.0.2492.0 canary (64-bit) on OSX 10.10.3

1) navigate to about:blank
2) open devtools
3) type into console: ’ontouchstart’ in document
    it should return false
4) toggle device mode on
5) reset all overrides (top left icon)
6) refresh the page
7) type into console: ’ontouchstart’ in document
    it should return false
8) select a touch device from the devicelist
9) refresh the page
10) type into console: ‘ontouchstart’ in document
     it should return true
11) toggle device mode off
12) refresh the page
13) type into console: ‘ontouchstart’ in document
      it should return false
14) toggle device mode on
15) refresh the page
16) type into console: ‘ontouchstart’ in document
    it should return true

17) [!] select a different touch device from the devicelist
18) refresh the page
19) type into console: ‘ontouchstart’ in document
    it should return true
20) toggle device mode off
21) refresh the page
22) [!] type into console: ‘ontouchstart’ in document
    it should return false, but returns true

Notice the lines marked with [!]. This bug happens when we select a touch device a second time.
This sounds like a related but separate issue, good find!  Please file a
separate bug and reference it here.
Project Member Comment 48 by, Aug 25 2015
The following revision refers to this bug:

commit f12cdbf02ca74fabda86296b94bc611a3f8eef3c
Author: andrei.borza <>
Date: Tue Aug 25 23:15:47 2015

Added myself to AUTHORS for  Issue 133915 .

BUG= 133915 
TEST=Related cr:

Review URL:

Cr-Commit-Position: refs/heads/master@{#345477}


Project Member Comment 49 by, Aug 26 2015
The following revision refers to this bug:

r201176 | | 2015-08-26T00:43:53.723991Z

Changed paths:

Fixes a bug where touch device scripts were not cleared on exit of device mode in devtools.

When selecting more than 1 touch device during device mode in devtools, only
the touchevent scripts for the last selected device are cleared upon exiting
device mode. Events such as 'ontouchstart', coming from previous devices,
will persist.

BUG= 133915 
TEST=Reproduction steps are in 

Review URL:
@rby... should I still file a bug for this? I've seen two tickets that both contained this issue but both were originally referring to a different bug. 
Meh, the fix has already landed here - it's ok to just leave it lumped in with this issue IMHO (although the underlying problem for this issue still isn't fixed).
Labels: Needs-Feedback
Rechecked the issue on Chrome version 47.0.2498.0 on Windows 8 Touch Device. On entering "ontouchstart" in console returns "null" value instead of 'False' or 'True'. Could some one please help us in verify this issue.
Just to update: Followed the steps mentioned in comment#46
Labels: -Needs-Feedback
Re #c52: it should be 
"ontouchstart" in document
This is either true or false. It should be fixed, and behave as described in #c46.
Comment 55 by Deleted ...@, Nov 17 2015
This issue still isn't fixed.
The "ontouchstart" in window  is alwayls true when the browser is switched pc status.
In short, the chrome browser supports the touch event, but there is not a touchscreen,
the touch event can not be fired.
Do you have a approach avaliable to fix the issue? My chrome version is 46.0.2490.86 m.
Thank you all first !!!
Labels: -Pri-1 Pri-2
Labels: -Pri-2 Pri-3 Cr-Platform-DevTools-Mobile
Blockedon: 584367
Components: Blink>Bindings
With the bindings work iclelland@ has done for  issue 584367  (, I wonder if it's now possible to (finally) fix this issue?

Ideally toggling DevTools touch emulation on and off would immediately update the prototype chains for everything marked RuntimeEnabled=Touch (ontouch* attributes, TouchEvent constructor and legacy createTouch/createTouchList APIs).  Requiring a reload for it to take full effect would be OK.
Interesting! I agree we can now improve this.

All the code operates in terms of OriginTrials though. Is it designed to be very specific to origin trials? For example, here we'd check a setting (will have to migrate away from RuntimeEnabledFeatures) and install touch attributes. We can (and should) do the same thing with orientationEvent.

@iclelland: are there any plans for reusing bindings work apart from origin trials?
The next thing that I want to do with this is to allow RuntimeEnabledFeatures to also be optionally added to an initialized V8 context (essentially merging RuntimeEnabled and OriginTrialEnabled into a single 'feature enable')

It sounds like that would work for touch events -- just that the trigger for adding the interface, rather than flags or origin trials, would be a toggle in devtools.

I still need to do a bit more work to make this all possible; there are several IDL configurations that the new bindings work doesn't support yet, and there are no plans yet for *disabling* already-installed features, but if you can work with that, then I can likely extend the framework to fit this use case.
Great! I will wait for the merge with RuntimeEnabled, and figure out the way from there.
iclelland@ did that work ever get done? Are we actually able to fix this now?
Project Member Comment 63 by, Aug 8
The following revision refers to this bug:

commit 17ffda1a19434a08a8ec98c947b60c2bb90046e1
Author: Dmitry Gozman <>
Date: Tue Aug 08 05:20:56 2017

[DevTools] Force TouchEventFeatureDetection when enabling touch

- Moves TouchEventFeatureDetection from RuntimeEnabledFeature to
  OriginTrialEnabled with a special name "...ForInspector".
- Adds support to enable specific feature to OriginTrials.
- Adds support for conditional features declared on NoInterfaceObjects
  implemented by other interfaces.
- Adds "Requires reload" note when toggling touch in DevTools frontend.
- Removes old ad-hock support via evaluating script from DevTools.
- Adds a test. Unfortunately, layout tests force touch detection, so
  it has to be a browser tests.

Bug:  133915 
Change-Id: I9faec2b5cd547414bf4b1cb70abbd7b0fe2ec6e6
Commit-Queue: Dmitry Gozman <>
Reviewed-by: Yuki Shiino <>
Reviewed-by: Kentaro Hara <>
Reviewed-by: Ian Clelland <>
Reviewed-by: Pavel Feldman <>
Cr-Commit-Position: refs/heads/master@{#492539}

Status: Fixed
I think this is Fixed now unless revert happens.
Sign in to add a comment