Closed Bug 1717464 Opened 3 years ago Closed 3 years ago

[Bug] Two finger scrolling on touchpad opens link dialog

Categories

(GeckoView :: General, defect)

Product:
GeckoView
Component:
General
Platform:
Unspecified
Android
Type:
defect

Tracking

(firefox94 fixed)

Status:
RESOLVED FIXED
Milestone:
94 Branch
Tracking Flags:
Tracking Status
firefox94 --- fixed

People

(Reporter: kbrosnan, Assigned: m_kato)

References

Details

Attachments

(2 files, 1 obsolete file)

apz.txt
31.12 KB, text/plain
Details
Bug 1717464 - Handle ACTION_CANCEL for TrackPad scroll. r=#geckoview-reviewers
48 bytes, text/x-phabricator-request
Details | Review

From github: https://github.com/mozilla-mobile/fenix/issues/20100.

Steps to reproduce

  • Open a page with many links, e.g., https://en.wikipedia.org/wiki/Firefox
  • Scroll with 2 fingers on touch pad until the pointer end up resting on a link.
  • Remove both fingers.
  • Then use a single finger on the touch pad to move the pointer a little but leave it pointing at a link when you lift your finger.

Expected behavior

Expectation is that the pointer simply is on the link but no clicking has occurred.

Actual behavior

Unwanted click is generated.

Device information

  • Device vendor / model and Android version: Lenovo Chromebook Duet running Chrome OS 93.0.4543.0 (Android 9)
  • Firefox for Android version: 91.0a1 (Build #2015817099)

Originally reported at https://github.com/mozilla-mobile/fenix/issues/3708#issuecomment-817533421 by @dchee2. CC @makotokato.

Change performed by the Move to Bugzilla add-on.

Component: General → Panning and Zooming
Product: GeckoView → Core

This is the first I hear of someone using Firefox for Android on a device with a touchpad (a Chromebook in this case).

It's not particularly surprising that this scenario is poorly supported.

Perhaps related to #1561927.

See Also: → 1561927

Hey Kevin, a few questions for the GeckoView team:

  1. Is this use case (running Firefox for Android on a Chromebook) considered to be supported?
  2. If so, has there been previous development work specific to Chromebooks done in the past, or has this scenario just largely worked out of the box?
  3. If so, is there someone on the GV team who has access to a Chromebook and may be able to help us investigate and fix this?
Flags: needinfo?(kbrosnan)
  1. About 5% of our users are on Chromebooks.
  2. very little specific Chromebook work has been done. In 89 there was a behavior change bug 1561927. That made scrolling not select text.
  3. Redirect to Emily about Chromebook owners on her team.
Flags: needinfo?(kbrosnan) → needinfo?(etoop)

My Chromebook has no touch panel (Lenovo S330. Trackpad only), but I cannot reproduce this... Hmm

Ah, I can reproduce this now on Lenovo S330.

Makoto, would you be able to work on this? Or will you provide information to diagnose/investigate this issue without Chromebooks? From the perspective of APZ stand point, MOZ_LOG="apz.inputstate:5,apz.inputqueue:5" would be a start point (the log will be pointless if the issue is underlying in ChromeOS or in GeckoView).

Flags: needinfo?(m_kato)
Attached file apz log (obsolete) —
Flags: needinfo?(m_kato)

Thanks for the log. So a suspicious point is;

 D/apz.inputqueue injecting new touch block ae047780 with id 15 and target b0e72000 
 D/apz.inputqueue scheduling main thread timeout for target b0e72000
 D/apz.inputqueue got a content response; block=13 preventDefault=0
 D/apz.inputqueue got a content response; block=15 preventDefault=1

Looks like the single finger movement were interpreted to a long press.

Chrome for Android on Chrome OS doesn't seems to assign longtap, so I cannot confirm whether this occurs on Chrome for Android on Chrome OS..

I've reviewed some of the background here (such as bug 1561927, its fix, the Chrome issue it links to, and the above APZ logs), and will try to summarize my understanding.

The first important observation here is in this configuration (Android on Chromebook) touchpad scrolls generate touch events.

That's not what happens on desktop platforms, where our widget code turns touchpad scrolls into pan gesture events.

On Windows, we do have a few devices whose touchpads produce touch events with two touch points. These are problematic for general scrolling, so we have a workaround where we turn them into pan gesture events (see bug 1511901 for details).

In this case, it looks like, at the Android system level, touchpad scrolling generates MotionEvents with a single pointer, which our widget code then turns into touch events with a single touch point.

The issue in bug 1561927 was that GeckoView sometimes turns motion events into mouse events, and it was doing so for touchpad scrolls (and the mouse events then caused text selection). The fix for that bug tries to detect the touchpad scroll case and turn them into touch events in that case.

Now, in this bug, we are observing that the user performs a one-finger touchpad movement:

Then use a single finger on the touch pad to move the pointer a little but leave it pointing at a link when you lift your finger.

which then triggers a link click.

The logs indicate the link click is the result of a long tap. This suggests the one-finger touchpad movement is still generating touch events. (The long tap then occurs because we have a tolerance threshold where if the finger does not move far away from the touch-start point, we consider it a tap rather than a touch-drag. This is consistent with the user moving the pointer "a little".)

To test this theory: Makoto, could you please check if one-finger touchpad movements can be used for scrolling?

If yes, I think we may want to change GeckoView to stop turning one-fnger touchpad movements into touch events, and turn them into mouse moves instead (without a mouse-down/mouse-up at the beginning/end).

If not, then we need to understand why the touch events do not trigger scrolling (additional logs with apz.controller:5 also included would be helpful in this case).

Flags: needinfo?(m_kato)
Severity: -- → S3
Attached file apz.txt —
Attachment #9234200 - Attachment is obsolete: true

To test this theory: Makoto, could you please check if one-finger touchpad movements can be used for scrolling?

Chromebook has no configuration to use one-finger scroll setting.

I attached new log with apz.controller and gesture. Also, when using debug build, the following warning is outputted.

09-07 17:20:14.527  9547  9547 I Gecko   : [Parent 9547, Unnamed thread bea34000] WARNING: Unhandled state upon single touch start: file /mozilla/mobile-aarch64/gfx/layers/apz/src/GestureEventListener.cpp:199
09-07 17:20:15.030  9580  9614 I Gecko   : [Child 9580, Main Thread] WARNING: Got an unexpected touchend: file /mozilla/mobile-aarch64/gfx/layers/apz/util/TouchCounter.cpp:58
Flags: needinfo?(m_kato)

(In reply to Makoto Kato [:m_kato] from comment #13)

I attached new log with apz.controller and gesture.

Thanks, though what I'm looking for is a log during a one-finger touchpad movement (I'd like to understand why it does not cause scrolling, if it's generating touch events). Any chance you could get one like that?

Also, when using debug build, the following warning is outputted.

09-07 17:20:14.527  9547  9547 I Gecko   : [Parent 9547, Unnamed thread bea34000] WARNING: Unhandled state upon single touch start: file /mozilla/mobile-aarch64/gfx/layers/apz/src/GestureEventListener.cpp:199
09-07 17:20:15.030  9580  9614 I Gecko   : [Child 9580, Main Thread] WARNING: Got an unexpected touchend: file /mozilla/mobile-aarch64/gfx/layers/apz/util/TouchCounter.cpp:58

This is suspicious, and seems to stem from:

D/apz.gesture Receiving event type 0 with 1 touches in state 5

but I'm unsure how we got into that state (would need to see what comes before in the log).

Flags: needinfo?(m_kato)

Ah, I may understand this after I debug this today.

After two-finger scroll is finished, when user taps trackpad, Android VM on Chrome OS tried to start more scroll event unfortunately, But then, it fires touch cancel event immediately. GV (not APZ) doesn't consider this situation.

Assignee: nobody → m_kato
Flags: needinfo?(m_kato)
Flags: needinfo?(etoop)

(In reply to Makoto Kato [:m_kato] from comment #15)

After two-finger scroll is finished, when user taps trackpad, Android VM on Chrome OS tried to start more scroll event unfortunately, But then, it fires touch cancel event immediately. GV (not APZ) doesn't consider this situation.

This confuses me that why the same symptom doesn't happen on Chrome. Does Chrome handle the case?

Anyway moving to GeckoView as per comment 15.

Component: Panning and Zooming → General
Product: Core → GeckoView

(In reply to Hiroyuki Ikezoe (:hiro) from comment #16)

(In reply to Makoto Kato [:m_kato] from comment #15)

After two-finger scroll is finished, when user taps trackpad, Android VM on Chrome OS tried to start more scroll event unfortunately, But then, it fires touch cancel event immediately. GV (not APZ) doesn't consider this situation.

This confuses me that why the same symptom doesn't happen on Chrome. Does Chrome handle the case?

Yes, now. It seems to be https://crbug.com/1199635.

Huh, it got resolved just before we got this issue report. That's unfortunate. :/

This will be a bug of Android VM on Chrome OS.

When touching trackpad, Android VM on Chrome OS might fire scroll event for
trackpad, then, it fires cancel event immediately.

Actually, since we don't consider this situation, APZ detects that this is
log tap unfortunately.

So we should dispatch ACTION_CANCEL as scroll event.

(In reply to Makoto Kato [:m_kato] from comment #15)

Ah, I may understand this after I debug this today.

After two-finger scroll is finished, when user taps trackpad, Android VM on Chrome OS tried to start more scroll event unfortunately, But then, it fires touch cancel event immediately. GV (not APZ) doesn't consider this situation.

Thanks for tracking this down!

Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/af5dd029bcc2
Handle ACTION_CANCEL for TrackPad scroll. r=geckoview-reviewers,agi

https://hg.mozilla.org/mozilla-central/rev/af5dd029bcc2

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox94: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: