1629111 - Click events delayed by 300ms with touch simulation enabled and page has a meta viewport

Status: VERIFIED FIXED

(DevTools :: Responsive Design Mode, defect, P3)

Description

[Florens Verschelde :fvsch]

When using touch simulation in RDM, I'm getting a systematic 300ms delay between touchend and click events. We're supposed to only get this delay on pages without a meta viewport.

Context from https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away:

For many years, mobile browsers applied a 300-350ms delay between touchend and click while they waited to see if this was going to be a double-tap or not, since double-tap was a gesture to zoom into text.

(...) As of Chrome 32 (back in 2014) this delay is gone for mobile-optimized sites, without removing pinch-zooming! Firefox and IE/Edge did the same shortly afterwards, and in March 2016 a similar fix landed in iOS 9.3.

RDM tries to emulate this modern behavior in:
https://searchfox.org/mozilla-central/source/devtools/server/actors/emulation/touch-simulator.js#292
https://searchfox.org/mozilla-central/source/devtools/server/actors/emulation/touch-simulator.js#455-510

This seems buggy in current Nightly.

Comment 1

[Florens Verschelde :fvsch]

Attachment: rdm-touch-simulation-click-delay.html

Test case.

• Chrome in RDM mode fires the click event just after touchend
• Firefox in RDM mode fires the click event 300ms after touchend

Comment 2

[Florens Verschelde :fvsch]

Attachment: rdm-touch-simulation-click-delay.png

Result in Firefox.
Using a meta viewport or not yields the same result.

Comment 3

[Florens Verschelde :fvsch]

Attachment: rdm-touch-simulation-click-delay-chrome.png

Result in Chrome DevTools. No delay between touchend and click events.

Comment 4

[Brad Werth [:bradwerth]]

Botond, we need some guidance here. There's some history where we have a 300ms delay between touchend and click, to give the platform time to detect a double-tap-to-zoom. But we only apply that delay when double-tap-to-zoom is allowed. When we simulate devices in RDM, we either need to use the same event pathways as used in GeckoView, or we need to spoof our touch events to match what those pathways do. We use the same event pathway whenever we can, but this might be a case where we still need to spoof and we want to make sure we match the behavior correctly.

So, is this the correct statement for when GeckoView adds a 300ms pause between touchend and click events: GeckoView adds a 300ms delay for double-tap-to-zoom in all cases except user-scalable=no.

Comment 5

[Botond Ballo [:botond]]

We add the delay whenever double-tap zoom is allowed. There are three reasons I'm aware of that double-tap zoom could be disallowed:

1. Zooming in general is disallowed, via user-scaleable=no.
2. The CSS viewport width, as specified via the width property in the meta viewport tag, is not wider than the device width. In such cases, double-tap zoom is disallowed (precisely to avoid this delay) even thoug pinch-zooming is still allowed. Note that this happens in the common case where the property value is width=device-width. I believe this is the case Florens is referring to in comment 0 (with this check being a heuristic for detecting a "mobile-optimized site").
3. The CSS touch-action property disallow double-tap zooming. Basically any value of this property other than auto has this effect.

Comment 6

[Micah [:mtigley] (she/her)]

In Bug 1623941, we recently removed manual firing of mouse events after "touchstart" in RDM and replaced it with a better-supported platform API sendNativeTouchPoint. When there is a metaviewport and double-tap zoom is disallowed (according to Botond's criteria in Comment 5), the 300ms delay isn't present using Florens' test case. This fix became available in Firefox Nightly (78.0a1), so we can close this issue now.

Please feel free to re-open if anyone is still experiencing this issue.

Comment 7

[Florens Verschelde :fvsch]

I'm getting good results with the attached test case:

0ms - touchstart
80ms - touchend
92ms - click

This is consistent with what Firefox Preview shows.