1816471 - Consider increasing ui.touch_activation.duration_ms

Status: RESOLVED FIXED

(Core :: Panning and Zooming, task, P3)

Description

[Dan Robertson (:dlrobertson)]

Summary

Now that the synthesized mouse events that are fired for a single tap gesture are immediately fired to content, we can increase the touch activation duration to a larger value. This should give users a better indication of which element they are activating.

Expected fix

Change ui.touch_activation.duration_ms (specified here) to a larger value (maybe 50?).

Historical info

Note: This bug was originally used to track the following, which was completed elsewhere.

After we implement bug 1774875, the preference ui.touch_activation.duration_ms will not be respected for non-scrollable elements. This may cause taps on non-scrollable elements with :active css rules to appear to not-enter the :active state, or at least the :active state will happen very very quickly. We should change the synthesized mouse events for the non-scrollable case to avoid clearing the active state. The :active: state of the element should be managed by the ActiveElementManager.

Comment 1

[Botond Ballo [:botond]]

(In reply to Dan Robertson (:dlrobertson) from comment #0)

This may cause taps on non-scrollable elements with :active css rules to appear to not-enter the :active state, or at least the :active state will happen very very quickly.

The intention of initially limiting the change to non-scrollable changes is to avoid regressing this: on such pages, ActiveElementManager will activate the element eagerly on touch-start here (since on non-scrollable pages, mCanBePan will be false), so the active state should last at least as long as the duration between the touch-start and touch-end events.

I suppose it's possible that that duration is itself shorter than 10ms; if we're concerned about this, we could start a 10ms timer on touch-start and trigger the element activation on the later of {the timer expires, the touch-end is received}. However, I'm not sure how likely that's to happen in practice.

Comment 2

[Botond Ballo [:botond]]

I believe this is covered by the patch in bug 1816473.

Comment 3

[Botond Ballo [:botond]]

Dan, perhaps we could repurpose this bug to track the following suggestion made in the review of bug 1816473:

consider increasing ui.touch_activation.duration_ms, now that it's no longer on the responsiveness critical path, to make the activation more user-noticeable

This would address some of the feedback we've had about the activation period being too brief (e.g. in bug 1806400).

(Alternatively, we could file a new bug for that, and close this one as a duplicate of bug 1816473.)

Comment 4

[Dan Robertson (:dlrobertson)]

We certainly could

Comment 5

[Dan Robertson (:dlrobertson)]

Updated the bug title and first comment

Comment 6

[Botond Ballo [:botond]]

Marking this as a good first bug per discussion in our team meeting.

Please note, someone looking to pick up this bug should ideally have a touchscreen device capable of running a Gecko-based browser (so either an Android phone or tablet, or a touchscreen laptop) to play around with different values of the setting and see its effect.

Comment 7

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1816471 - Increase the touch activation duration. r=botond

Now that the touch activation duration no longer impacts the timing of
synthesized mouse events for single-tap gestures, increase the duration.
This should give users a better indication of element activation, without
negatively impacting performance.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5dbe89396d7f
Increase the touch activation duration. r=botond

Comment 9

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/5dbe89396d7f