1273333 - Platform support for touch event simulation without reloading

Status: NEW

(Core :: DOM: Events, defect)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

: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.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 3

[Andrew Overholt [:overholt]]

Seems like we're waiting on some info.

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 6

[Daniel Bodea [:danibodea]]

Is this bug still valid?
There's a notification displayed at the top of the page after clicking the "hand" icon, telling the user that "Device simulation changes requires a reload to fully apply. Automatic reloads are disabled by default do avoid losing any changes in DevTools. You can enable reloading via the Settings menu.".
Thanks.

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Bodea Daniel [:danibodea] from comment #6)

Is this bug still valid?

Yes. The idea of this bug is to apply changes to touch support in the platform without reloading the page. The notification you mention is there to advise that currently we have to reload (because we haven't implemented the idea in the bug), but we would like to avoid the need to reload if possible.

Comment 8

[Peter Van der Beken [:peterv]]

(In reply to Olli Pettay [:smaug] from comment #5)

I don't understand how ontouch* could work without reload. Pages probably
don't try to set those properties if they aren't there.

Yeah, I don't think we're going to make this work. Properties on the prototypes are set up when the prototypes are created, I suspect that changing that set of properties (potentially also removing) after prototype creation is going to lead to plenty of weird issues with page scripts.