Current behavior: 1. Open some touch event test page like https://mozilla.github.io/mozhacks/touch-events/event-listener.html which adds touch event listeners 2. Enable touch simulation * Tools menu -> Web Developer -> Responsive Design Mode * Click "Hand" icon to enable touch simulation 3. Touch event listeners are ignored until the page is reloaded Desired behavior: Touch event listeners should respond without reloading the page. Other browsers: In Chrome's equivalent tool, touch simulation can be enabled without reloading.

:smaug, do you know if we are currently discarding touch event listeners entirely on desktop by default? Or perhaps you might know who would know. :) I know there is a pref "dom.w3c_touch_events.enabled" which controls whether touch events are enabled. We currently flip this on when using touch simulation. So far it appears touch event handlers are not recorded at all by the platform if it is disabled.

ontouch* properties aren't there in the interfaces at all when touch events are enabled. That is part of the feature testing. Also TouchEvent or Touch interfaces aren't exposed in the global scope. What does Chrome does here? If it always exposes those properties and interfaces, then this is just about enabling touch event firing. But it certainly isn't that for us. How do we enable "touch simulation"? Is that via enabling the pref? That would mean we enable touch event stuff everywhere and might lead to pages to break.

Seems like we're waiting on some info.

Sorry for the delayed reply! (In reply to Olli Pettay [:smaug] (high review load, please consider other reviewers) from comment #2) > ontouch* properties aren't there in the interfaces at all when touch events > are enabled. That is part of the feature testing. Also TouchEvent or Touch > interfaces aren't exposed in the global scope. > > What does Chrome does here? If it always exposes those properties and > interfaces, then this is just about enabling touch event firing. But it > certainly isn't that for us. Part of the reason for my delay is that there isn't really a simple answer for each browser. When I originally filed this bug, I only had various anecdotal experiences, which isn't helpful for a discussion. I've now collected more precise data about what's exposed and which events work in each browser: https://docs.google.com/spreadsheets/d/1h6MOfihxkmtqAG7Qb7DZwr2YxAmAWoScoHTP4qNbvSM/edit The good news is that we're currently doing better than Chrome as far as touch simulation without reloading, so that's great! For the scope of this bug, I am interested in trying to improve rows 10 - 12 (ontouchstart, etc. event handlers) so that they would receive events immediately once touch simulation is activated, instead of requiring a page reload first. It would also be nice to improve rows 4, 8, and 9 to expose all interfaces without a reload, but I don't think it matters as much in practice since the main reason those matter is for feature detection which likely happens on page load anyway (so a reload would still be needed for the page scripts to check the result again). > How do we enable "touch simulation"? Is that via enabling the pref? That > would mean we enable touch event stuff everywhere and might lead to pages to > break. At the moment, yes, we flip the pref "dom.w3c_touch_events.enabled", which I'll be the first to agree is pretty bad (since it affects all tabs). There is already work in progress in bug 970346 to create a way to enable touch events per docshell / tab, so I think we can ignore that issue in this bug. Along with flipping the pref to enable touch events, we enable a frame script[1] for the browser of interest which listens for mouse events and creates touch events from them. Chrome uses a different approach: they reconfigure their event handling code to believe it has a touch device[2], so in theory it would have the same behavior as Chrome Android. Looking at the test results, it only works partially, perhaps because some code paths are caching the "touch enabled" state. [1]: https://dxr.mozilla.org/mozilla-central/source/devtools/shared/touch/simulator-content.js [2]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/DevToolsEmulator.cpp?type=cs&sq=package:chromium&rcl=1463411924&l=322

I don't understand how ontouch* could work without reload. Pages probably don't try to set those properties if they aren't there. And we can't have ontouch* enabled for all the Elements and such if touch events are disabled, since ontouch* are being used as feature testing - unless we're brave and try to enable touch everywhere (meaning, enabling touch interfaces even on non-touch devices). Peterv is better person to say what kinds of changes we'd need in webidl bindings to be able enable/disable interfaces or properties on interfaces on fly.