745260 - mousedown should be triggered at the same moment than touchstart

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect)

Description

[Julien Wajsberg [:julienw]]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120403211507

Steps to reproduce:

Open http://chatillon.everlong.org/~flash/tests/touch/



Actual results:

On all mobile (touch) browsers I tested, the following events happen when I "touch" the first button :
- touchstart
- touchend
and then, like 400ms later, all 3 at the same time
- mousedown
- mouseup
- click



Expected results:

So, I quite understand why the click is triggered later. However, IMHO, mousedown should be triggered at the same moment than touchstart, and mouseup at the same moment than touchend. It would help making Web applications working in the same way on all devices.

I think the impact would be very low as nowadays web applications that are specifically designed for mobile use either click or touchstart; and evangelists even _do_ advise to use touchstart to get more responsive apps, like we used to use mousedown on traditional apps.

Hey, maybe we could even just make obsolete the touchstart/touchend events and use the good ol' mouse events with a 'touch' flag on it ?

Comment 1

[Patrick H. Lauke]

The 300ms delay is there for a reason (allowing double-tap to zoom). The order in which events are being fired (touch events first, then delay, then compatibility mouse events and click) is there for a reason (compatibility with existing content and the ability to handle touch exclusively while suppressing the generation of mouse compat events in the first place).

All (sensible) browsers follow this pattern, so it would be disingenuous in my view to try and break this.

On a related note, Pointer Events do fire compat mouse events inline. Any further effort will likely go towards this model, rather than trying to unilaterally change the behavior of touch events.

Comment 2

[Julien Wajsberg [:julienw]]

(In reply to Patrick H. Lauke from comment #1)
> The 300ms delay is there for a reason (allowing double-tap to zoom). The
> order in which events are being fired (touch events first, then delay, then
> compatibility mouse events and click) is there for a reason (compatibility
> with existing content and the ability to handle touch exclusively while
> suppressing the generation of mouse compat events in the first place).

Note that this would still be possible by calling preventDefault at touchstart.

> 
> All (sensible) browsers follow this pattern, so it would be disingenuous in
> my view to try and break this.

yes it's probably too late now :(

> 
> On a related note, Pointer Events do fire compat mouse events inline. Any
> further effort will likely go towards this model, rather than trying to
> unilaterally change the behavior of touch events.

Yeah I agree that pointer events is the way to go now.

Comment 4

[Patrick H. Lauke]

Just doing a bit of clean-up...wondering if this bug could/should be closed as invalid?

Technically firing mousedown directly after touchstart would not contravene the (current) letter of the TE spec http://www.w3.org/TR/touch-events/#mouse-events as long as

"the touchstart event type must be dispatched before any mouse event types for that action."

though note that later on the spec does suggest that the mouse ones should in effect be fired after touchend

"If the user agent intreprets a sequence of touch events as a click, then it should dispatch mousemove, mousedown, mouseup, and click events (in that order) at the location of the touchend event for the corresponding touch input"

with all that being said, work is currently under way to update/include errata for the TE spec, which will explicitly clarify when/how user agents fire mouse events, and it will be based on what user agents in the wild do...which is exactly what firefox does (first all the touch events, THEN the mouse events).

If nothing else, doing what's proposed here would create huge interop issues with current touch-optimised web content in the wild.

Comment 5

[Matt Brubeck (:mbrubeck)]

Agreed; making this change would break interoperability.

Comment 6

[Julien Wajsberg [:julienw]]

> If nothing else, doing what's proposed here would create huge interop issues with current 
> touch-optimised web content in the wild.

I won't fight much more here, but are we sure of this?

From what I see, web content tests for the existence of ontouchstart.
See for example [1]. Same lib also calls preventDefault for the touchstart event [2]. So this would basically work the same with my changes.
Hammer.js does the same, see [3] [4]. Their comment specifically says "most mobile browser also emit mouseevents, right after touchstart". I'm quite curious to know why they say "right after touchstart" rather than "right afte touchend". Maybe some touch devices are actually doing what I suggest?

Microsoft's polyfill for pointer events "if (window.ontouchstart !== undefined)" [5].

I haven't done an exhaustive check but it seems quite likely that websites supporting both touch and mouse events test that the "ontouchstart" property exists. Other websites just use mouse events, and they'd be glad that mousedown works faster.

[1] https://github.com/dbushell/Nestable/blob/master/jquery.nestable.js#L7
[2] https://github.com/dbushell/Nestable/blob/master/jquery.nestable.js#L106
[3] https://github.com/hammerjs/hammer.js/blob/master/src/input.js#L3-L5
[4] https://github.com/hammerjs/hammer.js/blob/28b0448e642f0458869d7e32d0a778d3327a1d86/src/input/touchmouse.js#L29-L35
[5] http://handjs.codeplex.com/SourceControl/latest#hand.base.js

Comment 7

[Patrick H. Lauke]

"Maybe some touch devices are actually doing what I suggest?"

None of the major platform/browser combinations do, no:

http://patrickhlauke.github.io/touch/tests/results/

"if (window.ontouchstart !== undefined)"

This checks for whether or not touch events are supported. Nothing more, nothing less (i.e. it's not useful to determine "is this a touch-only device" as there are touch and mouse capable things like touchscreen laptops). https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/

Comment 8

[Julien Wajsberg [:julienw]]

Yes I know, I was not suggesting otherwise. I also added links to hammer.js :) Hammer.js is using this check + user agent sniffing to distinguish touch+mouse from touch only. And they use "preventDefault" in the "touchstart" event.

Comment 9

[Patrick H. Lauke]

Additionally - let's assume a browser did what you suggest. Let's say it fires mousedown straight after touchstart. This would result in any finger touching the screen being interpreted as a mousedown. What happens with scrolling? Currently, browsers on touch devices need to first have a stab at recognising a gesture (is this a tap, a scroll, a pinch-zoom?) first before firing compatibility mouse events. In your proposed model, they wouldn't be able to work out the user's intent first...so the simple action of using my finger to scroll the page would start firing mousedown, mousemove, mouseup events...which, if nothing else, is non-standard behavior, and in the worst case can trigger unintended behavior, depending on the site.

Comment 10

[Julien Wajsberg [:julienw]]

I'm only talking about "mousedown" here, not mousemove/mouseup. The issue you're outlining is exactly the same than when we fire "touchstart".

Everytime a web developer is adding a handler for "touchstart" because it's "faster", it makes me cry. In the past we were doing this with "mousedown". So I was trying to make things look alike here. And I definitely didn't want that only us do the change, I agree it would need to be agreed with other engines (even if, after all, other engines don't ask us before doing incompatible changes).

The future-proof way is Pointer Events anyway, so ok, let's focus on making this right.

Comment 11

[vitto32]

This should happen at least when touchevents are disabled (dom.w3c_touch_events.enabled=0) but the device has a touchscreen. Such as in every windows 8.1 touch laptop / allinone on the market.
As far as touchstart is not fired it's not possible to have long presses, that's weird (IE and Chrome do act differently)