1951304 - Allow using double-tap to select text in input fields / text areas

Status: RESOLVED FIXED

(Core :: DOM: Selection, enhancement)

Description

[Marius Tippkämper]

Steps to reproduce:

(I can reproduce the problem on a Samsung Galaxy S25 and a Samsung Galaxy S22. I don't have any other Android devices available to test, so I don't know if this is Samsung specific.)

On an input field or text area on a website, double tap an existing word to select it.

Actual results:

The cursor jumps to the position of the double tap and a floating menu with "Paste" and "Select all" button appears

Expected results:

The double tapped word should be selected, the selection should be expandable by dragging the drop-shaped UI elements that mark the start and end of the selection, and the floating menu should have options for "Copy", "Cut", etc.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Fenix::Browser Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 3

[Jeff Boek [:boek]]

Not sure what the correct component is for this, if this isn't the right place could you please redirect it?

Comment 4

[Botond Ballo [:botond]]

I thought we had a "Layout: Text Selection" component for AccessibleCaret issues but maybe that's been folded into "DOM: Selection".

In any case: a specific URL that's affected would be helpful.

Comment 5

[Sean Feng [:sefeng211]]

Hi Marius,

As Botond said, if you can provide a specific URL about where you experiences this, that'd be helpful!

Comment 6

[Marius Tippkämper]

Uuh, any URL works for me. E.g. www.google.com. Or the text area I'm using to type this very text.

Recorded a screen capture where I try to double tap text in the text field of the Google search website. In any other app this would select the word.

Comment 7

[Marius Tippkämper]

Sorry, that wasn't meant to sound impolite. :D
Thanks for looking into it, everybody.

Comment 8

[Sean Feng [:sefeng211]]

The recording helped a lot..Yeah I am seeing the same thing, and I also expect the word to be focused.

I'll take a closer look. Thanks!

Comment 9

[Jan Jaeschke [:jjaschke]]

FWIW, I can't repro if I switch on Desktop mode on the device (I assume that's to be expected though)

Comment 10

[Botond Ballo [:botond]]

(In reply to Marius Tippkämper from comment #0)

The double tapped word should be selected, the selection should be expandable by dragging the drop-shaped UI elements that mark the start and end of the selection, and the floating menu should have options for "Copy", "Cut", etc.

In case you're looking for a workaround, long-pressing a word in an input field has these effects.

Comment 11

[Botond Ballo [:botond]]

Just to add one more piece of info: this does not seem to be a regression, at least not a recent one; Firefox for Android versions going back to at least 2020 behave this way.

Comment 12

[Sean Feng [:sefeng211]]

Clear my NI given I won't be able to work on this

Comment 13

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

This doesn't work on Windows either.

Comment 14

[soogbad]

Attachment: Bug 1951304 - Implement double-tap to select word in GeckoView. r=#geckoview-reviewers

Comment 15

[soogbad]

Attachment: Bug 1951304 - Implement double-tap to select word in GeckoView. r=#geckoview-reviewers

On Android, double-tapping text in a browser should select the word under
the tap, matching the behavior of native Android apps. Previously, Firefox
would instead show a paste/select-all menu without selecting a word.

This adds double-tap detection in GeckoView.dispatchTouchEvent (rather than
onTouchEvent, since the embedded SurfaceView consumes ACTION_DOWN before it
reaches onTouchEvent). On a detected double-tap, it dispatches a
GeckoView:SelectWordAt event with the raw screen coordinates to the
GeckoViewSelectionAction module, which forwards them via the
SelectionActionDelegate actor pair to SelectionActionDelegateChild in the
content process. There, windowUtils.selectAtPoint() with SELECT_WORDNOSPACE
selects the word at the converted client coordinates.

Comment 16

[soogbad]

Hello guys, I submitted a revision for this :)

Comment 17

[Makoto Kato [:m_kato]]

Originally, Gecko can select a word by double click. Even if double tap by touch event, Gecko can fire double click event. But unfortunately, Accessible Caret eats some events, then double click isn't dispatched.

When 1st tap, Accessible Caret state is PressNoCaretState. then 2nd tap becomes PressCaretState. When 1st tap, we will set a selection as collapsed. It means that caret mode is Cursor. So Accessible Caret is shown as cursor mode. When 2nd tap, AccessibleCaretManager::PressCaret returns successful because caret is shown. Then state becomes PressCaretState. PressCaretState's event handlers return eConsumeNoDefault. So double click isn't dispatched.

So if caret isn't shown on 2nd tap, double tap can select a word.

This caret is shown by AccessibleCaretManager::OnSelectionChanged. So If we can delay calling AccessibleCaretManager::OnSelectionChanged() (APZ's double tap timer default value is 200ms), or calling AccessibleCaretManager::UpdateCarets() from AccessibleCaretManager::OnSelectionChanged() on each state, I guess that we will be able to fix this.

Comment 18

[Makoto Kato [:m_kato]]

This caret is shown by AccessibleCaretManager::OnSelectionChanged. So If we can delay calling AccessibleCaretManager::OnSelectionChanged() (APZ's double tap timer default value is 200ms), or calling AccessibleCaretManager::UpdateCarets() from AccessibleCaretManager::OnSelectionChanged() on each state, I guess that we will be able to fix this.

"So If we can delay calling AccessibleCaretManager::OnSelectionChanged() (APZ's double tap timer default value is 200ms), or delay calling AccessibleCaretManager::UpdateCarets() from AccessibleCaretManager::OnSelectionChanged() on each state, I guess that we will be able to fix this." is correct.

Comment 19

[soogbad]

hold on m_kato I actually just managed to get a working double tap to select build using the c++ approach. let me update the revision and you can read the code yourself and tell me if that's what you mean

Comment 20

[soogbad]

Attachment: Bug 1951304 - Implement double-tap to select word in Android

On Android, double-tapping text in a browser should select the word under
the tap, matching the behavior of native Android apps. Previously, Firefox
would instead show a paste/select-all menu without selecting a word.

The root cause is that after the first tap places a cursor, the accessible
caret becomes visible. On the second tap, AccessibleCaretManager::PressCaret
succeeds (the caret is at the tap position), causing the ACE state machine to
enter PressCaretState, which returns eConsumeNoDefault for all events. This
prevents eMouseDoubleClick from being dispatched, so no word selection occurs.

Fix: in NoActionState::OnPress, detect when the incoming press is the second
tap of a double-tap (by comparing timing and position against the previous
press) and bypass PressCaret, instead transitioning directly to
PressNoCaretState (for touch events, preventing caret drag) or calling
SelectWordOrShortcut directly on the content PresShell (for APZ-synthesized
mouse events from the content process).

To support this, also:

• Add DoubleTapState to AccessibleCaretEventHub for handling eMouseDoubleClick
• Add TapType::eDoubleTapNoZoom and APZEventState::ProcessDoubleTapNoZoom to
  dispatch eMouseDoubleClick to content when double-tap zoom is not applicable
• Wire eDoubleTapNoZoom through AsyncPanZoomController::OnDoubleTap /
  OnSecondTap -> ChromeProcessController -> BrowserChild -> APZEventState

Comment 21

[soogbad]

i updated the revision. about your last two comments, copilot says:
Yes — our solution addresses exactly what the reviewer described, just through a different mechanism.

The reviewer's diagnosis:

1st tap → collapsed selection → OnSelectionChanged → UpdateCarets → caret becomes visible
2nd tap → PressCaret succeeds (caret is visible) → PressCaretState → eConsumeNoDefault → eMouseDoubleClick never dispatched
The reviewer's proposed fix: delay UpdateCarets by ~200ms so the caret isn't visible yet when the second tap arrives.

Our fix: detect the double-tap timing in NoActionState::OnPress and skip PressCaret when the second tap arrives within the window, regardless of whether the caret is visible. We skip PressCaretState for the same reason — preventing event consumption — but instead of hiding the caret, we recognize the double-tap directly.

The reviewer's delay approach is arguably simpler (no timing check needed), but has the downside that it would delay the caret appearing for every single tap by 200ms. Our approach is more targeted — it only activates on a detected double-tap without affecting single-tap caret latency.

Comment 22

[soogbad]

actually i created a new revision for the c++ approach and closed the java revision

Comment 23

[Makoto Kato [:m_kato]]

Back to DOM: Selection since this occurs on Windows (see comment #13)

Comment 24

[soogbad]

never had a problem with that on windows. might be a different problem that that specific user was having

Comment 25

[Jan Jaeschke [:jjaschke]]

I did look into this a while ago (llm assisted). This is not Android specific, it occurs on Windows as well if the device has touch input. I think this is APZ though, not DOM:Selection. (Sorry for playing ping-pong...)

Comment 26

[soogbad]

i see, that makes sense

Comment 27

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Unassigned soogbad per requested in https://phabricator.services.mozilla.com/D322046#11208233

Comment 28

[Botond Ballo [:botond]]

(Removing priority flag to ensure the bug appears in the new component's triage dashboard.)

Comment 29

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Attachment: Bug 1951304 - Use only CaretImage as the touch area for touch events. r?#layout

Bug 1809060 comment 4 has an image of the touch area: CaretImage (red box) and
TextOverlay (blue box). Full is CaretImage + TextOverlay.

This patch changes the touch area for touch events to use CaretImage, making it
behave the same as mouse events. As a result, any touch interaction near the
cursor on the TextOverlay now works. For example:

• double-tap to select a word
• long-tap to select a word
• single-tap to move the cursor

However, the trade-off is that dragging the caret by pressing the cursor or the
edge of the selection highlight stops working. Bug 2082580 tracks the work to
re-introduce it. This patch keeps the unused TouchArea::Full for the future
work.

Comment 32

[soogbad2]

Makes sense. So you removed the TextOverlay dragging feature, which solves both problems, and now the new bug you opened about it will be left for if people would want to work on bringing it back in the future

Comment 33

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Makes sense. So you removed the TextOverlay dragging feature, which solves both problems, and now the new bug you opened about it will be left for if people would want to work on bringing it back in the future

Exactly. Feel free to comment in bug 2082580 if you have any feedback.

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e1ccea708208
https://hg.mozilla.org/integration/autoland/rev/bc7a97109ee5
Use only CaretImage as the touch area for touch events. r=layout-reviewers,dshin

Comment 35

[Sandor Molnar[:smolnar]]

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

Comment 36

[Donal Meehan [:dmeehan]]

Did you want to nominate this for the Fx160 relnotes? If so, set the relnote-firefox flag to "?"
https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

Possible wording:

Fixed double-tapping a word in a text field on websites placing the cursor instead of selecting the word.

Comment 37

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Fixed double-tapping a word in a text field on websites placing the cursor instead of selecting the word.

The description is not accurate. I'll provide a wording below, but feel free to tweak it to meet the release note quality. Thanks!

Release Note Request (optional, but appreciated)
[Why is this notable]: It is a user perceivable fix that enables more touch actions near the cursor.
[Affects Firefox for Android]: Yes, and other desktop devices with touch events support.
[Suggested wording]: Fixed the touch actions near the cursor position in a text field, including double-tapping and long-tapping to select a word, and single-tapping to place the cursor.
[Links (documentation, blog post, etc)]: None.

Comment 38

[Donal Meehan [:dmeehan]]

Thanks, added to the Fx160 nightly release notes, please allow 30 minutes for the site to update. This will carry over to the Fx160 beta release notes and eventually the Fx160 release notes.