1798141 - Make single finger tap zoom easier to activate

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[bpdronkers]

User Agent: Mozilla/5.0 (Android 12; Mobile; rv:106.0) Gecko/106.0 Firefox/106.0

Steps to reproduce:

I installed Firefox Mobile to replace Google Chrome. But unlike in Chrome, double tapping with my thumb and then sliding up or down doesn't zoom in or out on a webpage. This is a standard feature across Android. Without a single finger double tap zoom (not scaling) it's not possible to conveniently browse while holding the phone with one hand. It's pretty much a no-go for Firefox.

Actual results:

No zooming in/out.

Expected results:

Zooming in and out.

Comment 1

[Makoto Kato [:m_kato]]

bpdronkers, we need more information to investigate this. Does this occurs on all web site? or specific web site? How to reproduce this?

Comment 2

[bpdronkers]

All websites. To simply reproduce, I installed the mobile browser and double tapping (where upon the second tap I'd expect to slide up and down to zoom) doesn't work.

Comment 3

[Makoto Kato [:m_kato]]

(In reply to bpdronkers from comment #2)

All websites. To simply reproduce, I installed the mobile browser and double tapping (where upon the second tap I'd expect to slide up and down to zoom) doesn't work.

When I use http://neverssl.com/, Firefox can zoom in/out by double tap. If web content has the limitation of zoom in/out, double tap does nothing.

Comment 4

[bpdronkers]

It works on http://neverssl.com but not on the majority of other websites. I'd like to use Firefox, but since Google Chrome mobile's double tap to zoom works on every site I'll continue using it till Firefox gains this feature across all sites. Hopefully your team can address in the future.

Comment 5

[Makoto Kato [:m_kato]]

I guess that [Settings] - [Accessibility] - [Zoom on all websites] is off as default. You should turn on it.

Comment 6

[bpdronkers]

I'll give it a whirl. I'm my opinion this should be on for all we sites. Phones are large these days and zooming with two fingers is tricky.

Comment 7

[bpdronkers]

Unfortunately turning the setting on will let me pinch zoom, but double tap zoom still doesn't work. Sorry!

Comment 8

[borayeris]

I'm disabled and I use double tap and slide to zoom on Chrome a lot, IF the site is not responsive. Double tap and slide don't work on Fenix as it supposed to work. Try https://bugzilla.mozilla.org/ on both Chrome and Fenix.

PS: We are in 2023 and how can bugzilla.mozilla.org still be non-responsive?

Comment 9

[Botond Ballo [:botond]]

I think there might be some confusion in this bug between two distinct gestures that we support:

1. Double-tap to zoom. This involves double-tapping on a content element that you'd like to zoom in on. It does not involve any sliding. Firefox zooms in by an amount it calculates to try and make the target element take up most of the (width of) the screen.
2. "Double-tap and slide". This involves one tap, followed by putting the finger back on the screen and sliding up or down. This zooms the page in or out, with the direction and amount determined by the finger movement. It's independent of what element you're tapping; it's basically an alternative way of activating "pinch-zoom". In the code we refer to this as "one-touch pinch" (originally implemented in bug 1111333), and it's controlled by the pref apz.one_touch_pinch.enabled (defaults to true on Android).

If I'm understanding the bug description correctly, it sounds like this bug is about #2 (whereas I suspect in comment 3 Makoto may have been trying #1).

Comment 10

[Timothy Nikkel (:tnikkel)]

Just tested, single finger tap zoom works for me (testing on bugzilla page).

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 12

[Botond Ballo [:botond]]

(In reply to borayeris from comment #8)

I'm disabled and I use double tap and slide to zoom on Chrome a lot, IF the site is not responsive. Double tap and slide don't work on Fenix as it supposed to work. Try https://bugzilla.mozilla.org/ on both Chrome and Fenix.

I compared one-touch pinch on bugzilla.mozilla.org on Fenix vs. Chrome, and I noticed that, while I'm able to activate the gesture in both, in Firefox the second tap has to happen pretty quickly after the first, whereas in Chrome you can have a larger interval between them and it will still be activated.

@bopdronkers, @borayeris: could you check if a doing the gesture with a shorter interval between the first tap and the slide makes the gesture work for you?

If there are sites where you're not able to activate the gesture at all (suggesting an additional issue), could you provide a specific example URL please?

Comment 13

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #12)

I compared one-touch pinch on bugzilla.mozilla.org on Fenix vs. Chrome, and I noticed that, while I'm able to activate the gesture in both, in Firefox the second tap has to happen pretty quickly after the first, whereas in Chrome you can have a larger interval between them and it will still be activated.

Anyways, this is something we should definitely adjust to make the gesture easier to activate in Fenix.

Comment 14

[bpdronkers]

Here's an example website: http://info.cern.ch/hypertext/WWW/TheProject.html

Double tap and slide doesn't zoom in or out. A quick double tap zooms the page an arbitrary amount. Pinch zoom with two fingers does work.

The goal here should be to replicate the functionality of two finger pinch zoom with a double tap with sliding the finger upon the second tap to manually zoom in or out at the desired zoom level. And right now that doesn't work, even when enabling zoom on all webpages in the accessibility settings.

Comment 15

[Botond Ballo [:botond]]

(In reply to bpdronkers from comment #14)

Here's an example website: http://info.cern.ch/hypertext/WWW/TheProject.html

I'm able to activate one-touch pinch on this site.

I suspect it's just the issue I mentioned in comment 12, where the slide has to happen fairly quickly after the tap, that's making it seem like it doesn't work. Let's fix that (increasing the allowed interval) and then re-test.

Comment 16

[bpdronkers]

I now understand what you mean about quick sliding. I thought the double tap itself had to be quick. What id suggest is no time out at all. As long as the finger doesn't leave the screen on the second tap, then you should be able to wait as long as you want before sliding the finger up or down. IMO. Or at least 3 seconds. There is no timeout on Chrome.

Comment 17

[bpdronkers]

I now understand what you mean about quick sliding. I thought the double tap itself had to be quick. What id suggest is no time out at all. As long as the finger doesn't leave the screen on the second tap, then you should be able to wait as long as you want before sliding the finger up or down. IMO. Or at least 3 seconds. There is no timeout on Chrome.

Comment 18

[Botond Ballo [:botond]]

(In reply to bpdronkers from comment #17)

I thought the double tap itself had to be quick.

Based on additional experimentation, it's actually both: the two touches have to be sufficiently close to each other in time, and the sliding motion has to start sufficiently soon after the second touch-down. We are stricter than Chrome in both respects, and we should make adjustments to both.

For the interval between the two touches, we can increase it (but not too much, since it impacts the responsiveness of interpreting the first touch as a single tap in the case where it's not followed by a second touch).

For starting the slide after the second touch down, you're right that Chrome doesn't seem to have a timeout, and I can't think of a reason we'd need one either.

Comment 19

[Frank Griffith Jr]

Tracking as part of Epic FFXP-2474

Comment 20

[bpdronkers]

Really appreciate the Mozilla team!

Comment 21

[Daniel Holbert [:dholbert]]

(Triaging S1/S2 bugs, and noticed this is "unconfirmed" - is that still accurate or should we mark this as "new" i.e. confirmed?)

Comment 22

[Botond Ballo [:botond]]

Yeah, this is confirmed and on our roadmap. (We haven't been very consistent about updating UNCONFIRMED vs. NEW statuses in this component, but perhaps we should...)

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:botond, since the bug has high severity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

Comment 24

[Botond Ballo [:botond]]

The bug is actionable, we have a plan for it summarized in comment 18. It's on our roadmap with Alex [:ajakobi] planning to pick it up as his next bug.

Comment 25

[Alex Jakobi [:ajakobi]]

Attachment: Test page logging touchstart and touchend timings

I compared the timings of touchstart, touchend and click as well as double click between Firefox and Chrome. From that it shows that Chrome is indeed less strict with timings that trigger a double click.

The test page is also accessible here.

The following timings did not trigger a double click in Firefox (too slow):

∆ Start/End: 110 ms
∆ Start/Start: 228 ms
∆ End/Start: 117 ms

The following timings did trigger a double click in Chrome:

∆ Start/End: 140 ms
∆ Start/Start: 412 ms
∆ End/Start: 269 ms

It would have been interesting when the single finger tap timer times out on Chrome and if that ends up creating a click event. But inspecting this collides with long tap being triggered, and so far I couldn't find a way to disable that in Chrome.

Comment 26

[Botond Ballo [:botond]]

This is admittedly confusing, but I believe "double-tap gestures" and "dblclick events" are two different things.

The latter is a mouse event gesture, synthesized when two mousedown/mouseup pairs occur in quick enough succession, and results in a synthesized dblclick event being dispatched to web content.

The former is a touch event gesture, synthesized when two touchdown/touchup pairs occur in quick enough succession, and results in zooming in (a behaviour implemented at the browser level), without any synthesized event being dispatched to web content.

What adds to the confusion here is that a touchdown/touchup pair also results in a mousedown/mouseup pair being synthesized (which in turn can contribute to an eventual dblclick event), but this only happens if the touchdown/touchup pair is being treated as a single tap by APZ. If APZ gesture-detects a double-tap, mouse events are not synthesized at all.

The reason you're not seeing double-tap-to-zoom on this test page is that double-tap gestures are disabled on pages with width=device-width in the meta viewport tag. The reason for this is that such pages are assumed to be mobile-optimized, such that the user shouldn't need to zoom in to achieve a comfortable reading/viewing level, and we consider it a better tradeoff to avoid the responsiveness penalty incurred by double-tap gesture detection (having to wait 300ms before treating a touchdown/touchup pair as a single tap).

So, to get the measurement we want, we'll need to:

1. Test with a page with a wide viewport. Removing the width=device-width from the meta viewport tag should be sufficient (that will result in the default viewport width of 980px being used, which is generally wider than phone screens when the device scale is taken into account). Alternatively, an explicit large value can be specified such as width=2000.
2. Record the timestamp when a click event is received after a single tap, and measure the elapsed time since the touchstart and touchend events were received. This indicates how much time the user has to do a second tap before the gesture is "locked in" as a single tap (as indicated by the click event being fired) and the user no longer has an opportunity to turn it into a double-tap.

Comment 27

[Alex Jakobi [:ajakobi]]

Attachment: Test page logging touchstart and touchend timings

I have added printing the timings from touchstart to click and from touchend to click for a single tap.

The results for Firefox and Chrome are similar and in the ballpark of this:

∆ Start/Click: 300 ms
∆ End/Click: 250 ms

Comment 28

[Alex Jakobi [:ajakobi]]

Attachment: Test page logging touchstart and touchend timings

Adding the corrected test page with content="width=2000". The results for this test page are in the comment above.

Comment 29

[Botond Ballo [:botond]]

Thanks, that seems to confirm that Chrome is using the same timeout value for double-tap gesture detection as we are (300ms).

A good next step would be:

• Check if you can replicate my finding in comment 18 that Chrome is less strict than Firefox in how close in time the two touches need to be in order to activate the one-touch pinch gesture
• See how those time intervals compare to the 300ms interval for double-tap detection

Comment 30

[Alex Jakobi [:ajakobi]]

It looks like that we are always using the first finger touch down as the beginning of our 300ms interval because when creating the max tap timeout task, we calculate a remaining delay based on the beginning of the touch block.

Here are two log outputs that seem to support this idea.

Log 1: Pinch gesture successfully activated:

17:12:19.005 SetState: GESTURE_NONE --> GESTURE_FIRST_SINGLE_TOUCH_DOWN
17:12:19.005 CreateMaxTapTimeoutTask() remaining delay: 297
17:12:19.044 CancelMaxTapTimeoutTask
17:12:19.044 SetState: GESTURE_FIRST_SINGLE_TOUCH_DOWN --> GESTURE_FIRST_SINGLE_TOUCH_UP
17:12:19.044 CreateMaxTapTimeoutTask() remaining delay: 259
17:12:19.166 HandleInputTouchSingleStart: SecondTapIsFar == false
17:12:19.166 SetState: GESTURE_FIRST_SINGLE_TOUCH_UP --> GESTURE_SECOND_SINGLE_TOUCH_DOWN
17:12:19.224 CancelMaxTapTimeoutTask
17:12:19.224 SetState: GESTURE_SECOND_SINGLE_TOUCH_DOWN --> GESTURE_ONE_TOUCH_PINCH
17:12:26.735 SetState: GESTURE_ONE_TOUCH_PINCH --> GESTURE_NONE

Log 2: Pinch gesture not activated

17:13:30.140 SetState: GESTURE_NONE --> GESTURE_FIRST_SINGLE_TOUCH_DOWN
17:13:30.141 CreateMaxTapTimeoutTask() remaining delay: 300
17:13:30.306 CancelMaxTapTimeoutTask
17:13:30.306 SetState: GESTURE_FIRST_SINGLE_TOUCH_DOWN --> GESTURE_FIRST_SINGLE_TOUCH_UP
17:13:30.306 CreateMaxTapTimeoutTask() remaining delay: 135
17:13:30.404 HandleInputTouchSingleStart: SecondTapIsFar == false
17:13:30.404 SetState: GESTURE_FIRST_SINGLE_TOUCH_UP --> GESTURE_SECOND_SINGLE_TOUCH_DOWN
17:13:30.444 HandleInputTimeoutMaxTap: state GESTURE_SECOND_SINGLE_TOUCH_DOWN
17:13:30.446 SetState: GESTURE_SECOND_SINGLE_TOUCH_DOWN --> GESTURE_NONE

Comment 31

[Botond Ballo [:botond]]

Ok, so the "remaining delay" calculation answers the question we had about why we never see the gesture activated with the interval between the two taps being longer than 300ms. (This is probably fine, it was more just a point of curiosity.)

The second log in comment 30 shows something else that's interesting though: the 300ms timeout can cancel the gesture even if the second finger has already gone down (we are in the GESTURE_SECOND_SINGLE_TOUCH_DOWN state, but not the GESTURE_ONE_TOUCH_PINCH state yet).

Since the condition for entering the GESTURE_ONE_TOUCH_PINCH state is that we get a touch-move event in the GESTURE_SECOND_SINGLE_TOUCH_DOWN state that's far enough from the touch-start position of the second tap that it overcomes the "touch start tolerance" threshold, that means the user needs to accomplish all that (including starting to move their finger) within the 300ms budget. (This also explains why, looking at the timing of the second touch-start event (which is sent as soon as the finger goes down), we haven't seen time intervals that are very close to 300ms either in cases where the gesture is successfully activated.)

So, I think this points to a clear direction for improvement: if the second finger goes down within the 300ms interval, we should cancel the timer at that point, and let the user do the additional step of starting to move their finger at their leisure.

Comment 32

[Alex Jakobi [:ajakobi]]

(In reply to Botond Ballo [:botond] from comment #31)

So, I think this points to a clear direction for improvement: if the second finger goes down within the 300ms interval, we should cancel the timer at that point, and let the user do the additional step of starting to move their finger at their leisure.

I agree. However, that would change the behavior for double tap a little: The user would now be able to hold down the second touch as long as they please and as soon as it gets lifted a TAPGESTURE_DOUBLE event would get sent to be handled by APZ. Are we okay with that?

Comment 33

[Botond Ballo [:botond]]

(In reply to Alex Jakobi [:ajakobi] from comment #32)

(In reply to Botond Ballo [:botond] from comment #31)

So, I think this points to a clear direction for improvement: if the second finger goes down within the 300ms interval, we should cancel the timer at that point, and let the user do the additional step of starting to move their finger at their leisure.

I agree. However, that would change the behavior for double tap a little: The user would now be able to hold down the second touch as long as they please and as soon as it gets lifted a TAPGESTURE_DOUBLE event would get sent to be handled by APZ. Are we okay with that?

Good question. I think as a user my expectation would be no: if the second touch is held down long enough, the gesture should only be eligible to be a one-touch pinch, and if the finger is lifted we can think of that as a one-touch pinch with no actual zoom change. We should double-check the Chrome behaviour though to ensure we try to stay consistent.

Comment 34

[Alex Jakobi [:ajakobi]]

(In reply to Botond Ballo [:botond] from comment #33)

Good question. I think as a user my expectation would be no: if the second touch is held down long enough, the gesture should only be eligible to be a one-touch pinch, and if the finger is lifted we can think of that as a one-touch pinch with no actual zoom change.

I agree.

We should double-check the Chrome behaviour though to ensure we try to stay consistent.

Chrome does not cancel the double tap gesture after a certain amount of time. I can hold down my finger for several seconds and still see double tap gesture being performed upon lifting my finger. Same goes for the one touch pinch.

I'll stay consistent with Chrome.

Comment 35

[Botond Ballo [:botond]]

(In reply to Alex Jakobi [:ajakobi] from comment #34)

(In reply to Botond Ballo [:botond] from comment #33)

Good question. I think as a user my expectation would be no: if the second touch is held down long enough, the gesture should only be eligible to be a one-touch pinch, and if the finger is lifted we can think of that as a one-touch pinch with no actual zoom change.

I agree.

We should double-check the Chrome behaviour though to ensure we try to stay consistent.

Chrome does not cancel the double tap gesture after a certain amount of time. I can hold down my finger for several seconds and still see double tap gesture being performed upon lifting my finger. Same goes for the one touch pinch.

I'll stay consistent with Chrome.

Sounds good. We can always adjust this aspect of the behaviour in a follow-up change if we want to.

Comment 36

[bpdronkers]

Offering a perspective from a user (I'm by no means a coder): being consistent with Chrome would probably be the best choice. Especially if we're hoping to lure folks over from that browser. Excited to see all the chatter in this feed. Thanks all for addressing this!

Comment 37

[Alex Jakobi [:ajakobi]]

Attachment: Bug 1798141 - Cancel tap and long tap timeout after second touch. r?botond

Comment 38

[Alex Jakobi [:ajakobi]]

(In reply to bpdronkers from comment #36)

Offering a perspective from a user (I'm by no means a coder): being consistent with Chrome would probably be the best choice. Especially if we're hoping to lure folks over from that browser. Excited to see all the chatter in this feed. Thanks all for addressing this!

Thanks for your input on this. We try to stay as close to Chrome with this as possible.

We have a draft for a possible improvement and created an example app from it. If you like to, you could try it out and let us know if that improves things for you.

You can find the Android apk here.

Here's a guide on how to install an apk on Android.

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2b164a9e57e2
Cancel tap and long tap timeout after second touch. r=botond

Comment 40

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/2b164a9e57e2

Comment 41

[Botond Ballo [:botond]]

Thanks Alex for your work on this!

@bpdronkers, @borayeris, if you have feedback on the new behaviour (available starting from Firefox 125), please don't hesistate to share it in a comment here or in a new bug.