Open Bug 1809060 Opened 1 year ago Updated 1 year ago

Double-tap-to-select usually doesn't work, in textareas

Categories

(GeckoView :: General, defect, P3)

All
Android

Tracking

(Not tracked)

People

(Reporter: dholbert, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached file testcase 1

[I'm spinning this off from https://github.com/mozilla-mobile/fenix/issues/2038 for a part of the original report there that @VitasLoWang just pointed out is still broken.]

tl;dr: Normally when you double-tap a word in Fenix, that word gets selected. But in a textarea, double-tapping does not cause the word to be selected.

STR:

  1. Load the attached testcase.
  2. Double-tap a word in the textarea.

EXPECTED RESULTS:
The word should be selected.

ACTUAL RESULTS:
No text is selected; instead, the caret moves and the context-menu appears. (The first tap places the caret and the second tap pops up the context-menu, I think?)

For comparison: if you double-tap a word in the regular div (outside of the textarea), then it does get selected. So this double-tap-to-select is indeed a gesture that we have implemented; it just doesn't work in textareas (or editable fields in general, probably).

DEVICE/VERSION INFO:
I'm using a Google Pixel 6a with Android 13.
Firefox Nightly 110 gives ACTUAL RESULTS (and it seems versions at least as far back as 2019 did as well, per https://github.com/mozilla-mobile/fenix/issues/2038#issue-437315539 )
Chrome 108 gives EXPECTED RESULTS.

Clarifying: every once in a while, double-tap does actually successfully select a word for me (in a textarea), but usually it does not.

So it seems like there might be some sort of fiddliness regarding about how we interpret the double-tap and whether we classify it as a double tap vs. as two distinct taps that happen to be (nearly) on the same spot.

Summary: Double-tap-to-select doesn't work in textareas → Double-tap-to-select usually doesn't work, in textareas

(CC'ing two folks who I know have worked on text input & selection implementation-details.)

I don't know about special handling in Android...

(Attached a screenshot originally from bug 1292904 Comment 18 to better explaining AccessibleCaret's touch area.)

When AccessibleCaret received a touch event (not a mouse event), its touch area are the red box (around the blue caret) plus the blue box (around the blinking cursor). The blue box was there so that people can drag the blinking cursor area to move the caret. It's a legacy design from Firefox OS era.

AccessibleCaret doesn't implement double-tap specifically, so in non-editable text, the double-tap is handled by general event handler in gecko. However, in an texarea, the first tap brings up the AccessibleCaret, and the second tap is likely to hit within the blue box, which brings up the context menu (paste, select all, etc). The second tap will be consumed by AccessibleCaret, so it won't be consider as a double-tap.

I feel it's possible to make AcccesibleCaret smarter on recognizing a double-tap.

Severity: -- → S3
Rank: 311
Priority: -- → P3

I've also experienced this with contenteditable.

Working on a mobile app that makes heavy use of contenteditable (backed by lexical for what it's worth) it is nearly impossible to select the text in Fenix using a double-top but works without problem in Chrome.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: