1652851 - Long press to select the text, links, or pasting copied text takes too much time

Status: RESOLVED FIXED

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

Description

[Emily Kager [:ekager]]

Originally filed as https://github.com/mozilla-mobile/fenix/issues/10618
I'm assuming because the text selection menu routes from GV this should be filed here, but correct me if I'm wrong!

Steps to reproduce

1. Long press to select text or a link
2. Notice that it takes almost 2 to 3 seconds to select the text or link and even pasting the copied link or text.

Expected behavior

Long press to select text or a link or pasting a copied link or text must not take 3 seconds, in chrome browser I can do it almost immediately.

Actual behavior

Takes a lot of time to select text, link or pasting the copied link/text.

Device information

• Android device: Motorola One Power, Android 10
• Fenix version: 76.0.0-beta.1 (Build #2015737667) and Nightly 200511 06:21 (Build #2015739635)

Addtl comment from mcomella: we have two theories 1) a threshold is defined that delays the pop-up from appearing and it's currently too long or 2) the threshold is fast enough but it's hard to get the proper alignment to trigger it - it requires more precision and less movement, manifesting itself as longer delay.

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

The timeout value used to detect a long press is in the pref "ui.click_hold_context_menus.delay", which is currently 500 (milliseconds). I would say that's pretty close to what I'm seeing here on a Pixel 4 trying to select text in Google search results. I believe this is the default timeout for Android as well, though I guess you can customize it. Emily are you seeing the 2-3s everywhere, or just certain pages? You could try adjusting that pref via about:config to see if you can get it to behave closer to what you expect. We should probably just use the value of ViewConfiguration.getLongPressTimeout().

Comment 2

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

Left a comment with some suggestions to try: https://github.com/mozilla-mobile/fenix/issues/10618

At this point it's not clear that there's anything to fix on the APZ side, and all the discussion has been happening on the fenix issue, so I'm going to close this bug. Once the issue is better diagnosed we can reopen this if needed.

Comment 3

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

A user reproducing this problem helpfully provided logs which shows what the problem is. Full analysis here but the quick summary is that the finger never exits the mini-slop zone, so APZ never sends a touchmove to content, so content never responds with the content response, so APZ waits for the content response timeout before feeding the inputs into the GestureEventListener. So the total time before the contextmenu event is dispatched is content_response_timeout + click_hold delay, which is 1100ms on mobile.

This might be hardware specific, if the hardware is holding the touchmove events stationary as an "aid" to the user, or if it's mis-reporting the DPI so our slop zone calculation is wrong. But even so I think we need to maybe add a mechanism to forcibly go straight from "inside the slop zone" to "a long-press happened".

Comment 4

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2df5aca6553b8bef7f11e5ec78c6c5d2aa429af6

Comment 5

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

Attachment: Bug 1652851 - Shorten GestureEventListener delayed tasks by the content response wait. r?botond

Touch inputs that go to the GestureEventListener often have to wait in the
InputQueue for some time as well, until the content response arrives. However,
that delay is not accounted for in the GestureEventListener delays. This can
result in the gesture being artificially delayed from a user's perspective.

This patch computes the amount of time the input event already waited in the
input queue, and shortens the delays used in the GestureEventListener
accordingly.

Comment 6

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

Attachment: Bug 1652851 - Force touch blocks in slop to be processed after the long-tap delay. r?botond

If the content response timeout is longer than the long-tap delay (which is
true given the current default pref values), and a touch block waits for the
entire content response timeout period, then the long-tap gesture gets delayed
by the difference in the timeouts. This can happen if the input block remains
in the slop state (and therefore never dispatches a touchmove to content,
thereby preventing the content from producing a content response). This patch
catches this scenario and installs a long-tap timeout in the InputQueue to
force the input block along.

Depends on D88009

Comment 7

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

Attachment: Bug 1652851 - Add some gtests to exercise the fixes. r?botond

In order to have the test be able to control the time better we need to do
a bit of hack-ish exposing of the frame time.

Depends on D88010

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/abba926fb2a5
Shorten GestureEventListener delayed tasks by the content response wait. r=botond
https://hg.mozilla.org/integration/autoland/rev/faee29a2448b
Force touch blocks in slop to be processed after the long-tap delay. r=botond
https://hg.mozilla.org/integration/autoland/rev/01a6b233e68e
Add some gtests to exercise the fixes. r=botond

Comment 9

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/abba926fb2a5
https://hg.mozilla.org/mozilla-central/rev/faee29a2448b
https://hg.mozilla.org/mozilla-central/rev/01a6b233e68e

Comment 10

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

Not sure this is worth uplifting, seems like the bug should be easy to work around for people that hit it.