1016480 - preventing default action of touchend event should cancel synthetic click event

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Mike Taylor [:miketaylr]]

Attachment: Test case

Currently calling preventDefault() on a touchend event does not cancel the synthetic click event that comes after. We should add that for compatibility with current Chrome Mobile and iOS Safari.

This breaks sharing videos on Vimeo.com and playback for tablet users (also on vimeo).

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Is this specced anywhere? AFAIK preventDefault() is only respected on touchstart and the first touchmove event.

Comment 2

[Mike Taylor [:miketaylr]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> Is this specced anywhere? AFAIK preventDefault() is only respected on
> touchstart and the first touchmove event.

My read on "touchend" at <http://www.w3.org/TR/touch-events/#list-of-touchevent-types> is that it is cancelable and the default action is (or can be) a click.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Matt, do you agree that prevent default action on a touchend should prevent clicks? Does that mean we have to insert another 300ms delay before the click?

Comment 4

[Matt Brubeck (:mbrubeck)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> Matt, do you agree that prevent default action on a touchend should prevent
> clicks?

If the research in bug 966919 comment 20 is correct that current versions of Chrome and Safari prevent clicks when touchend is canceled, then definitely yes.

> Does that mean we have to insert another 300ms delay before the click?

Hmm, good question.  I think we can avoid that, if we're careful.  We should be able to dispatch the simulated click events (or not) as soon as any "touchend" listeners have finished executing, which we can know synchronously in the content process.  So for example the content process could just ignore a "singletap" message if the preceding touchend event was canceled, as long as those messages are sent in that order (touchend before singletap).

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Ok, thanks. That makes sense.

Comment 6

[Florian Bender]

(In reply to Richard Maher from bug 776030 comment #8)
> Related to 978438 and FWIW: -
> 
> I think it is important for the accompanying documentation to point out
> that, when trying to disable default mouse event emulation from touch
> events, event.preventDefault() should ONLY be called from the touchend
> event. Otherwise any touchcancel or touchleave events are just not gonna
> happen.
> 
> To me https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Touch_events
> lacks clarity on this.

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Now that we are using APZ in Fennec this should be fixed. I tried the attached test case but it's not clear to me from reading the code how the behaviour of the test case would be different with and without this bug, because I didn't see a click handler on the share button.

Comment 10

[Mike Taylor [:miketaylr]]

> I tried the attached test case but it's not clear to me from reading the code how the behaviour of the test case would be different with and without this bug, because I didn't see a click handler on the share button

IIRC, this was more about the synthetic click being dispatched on content that appears later (with its own click handler). That said, I can confirm this is no longer an issue in 48.