1581007 - Unable to select a word in text fields if the cursor is already within the word

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Chris Peterson [:cpeterson]]

STR

1. Open Wikipedia: https://en.m.wikipedia.org.
2. Enter some words in the "Search Wikipedia" text field.
3. Try to select an individual word by long pressing it or double tapping it.

Expected Result

The individual word is selected like in Chrome.

Actual Result

The individual word cannot be selected in Fenix Nightly (GeckoView 71), Focus (GeckoView 69), or Fennec 68. The browsers instead show popup menu with "PASTE | SELECT ALL" options.

This bug was originally reported in the Fenix issue tracker:
https://github.com/mozilla-mobile/fenix/issues/2038

Comment 1

[Chris Peterson [:cpeterson]]

Sending to [layout:triage-discuss]. Is Gecko Layout responsible for highlighting of selected words in a text field? Or is this an Android system UI?

Comment 2

[Cameron McCormack (:heycam)]

Gecko is responsible for this, though I'm not sure where this is handled. Masayuki, do you know where long tapping to select a word is handled?

I actually wasn't aware that double tapping to select a word was an Android platform convention. I've always long tapped. Long tapping works on that Wikipedia search box works for me in Firefox Preview and Fennec. Double tapping doesn't, though does in non-editable content.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that we should follow native widget behavior unless it's wanted by most users (like sub-frame scrolling with mouse wheel on Windows).

Currently, Gecko handles double click on indivisual word in nsFrame::HandleMultiplePress(). I'm not familiar with long press handling, I guess the long press is handled by AccessibleCaret and the handler must be here:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/layout/base/AccessibleCaretManager.cpp#485-615
However, according to the symptom, somebody hooks long-tap before Gecko since in my understanding, context menu on Android is not managed by Gecko.

Similar to double tapping, I guess somebody handles it to pop up context menu before Gecko.

Comment 4

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

I guess the long press is handled by AccessibleCaret and the handler must be here:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/layout/base/AccessibleCaretManager.cpp#485-615

Right. Long pressing to select a word is processed by AccessibleCaret.

Chris, could you confirm a details of your STR in comment 0.

Suppose you enter "Mozilla Firefox" in the search field, where the blinking cursor is in the middle of the word "Firefox" like Mozilla Fire|Fox, and the compose of the word is compete, i.e. there's no underline for spell correction, etc. Under this circumstances, you can select "Mozilla" by long pressing on it, but you cannot select "Firefox".

If the above is true, then the reason behind this is that the touch area of the blue caret is actually extended to cover the blinking caret (the blue area in https://bugzilla.mozilla.org/attachment.cgi?id=8781001 from bug 1292904 comment 18). It was designed so that you can drag the blue caret even if you have a fat finger and do not press exactly on the blue caret.

We always extend the touch area regardless whether there is a selection range or not. If we'd like to exclude the touch area that cover the text when there's only a blinking cursor, which means we want to priorize selecting a new word over dragging the caret, I maybe can investigate how to do it.

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #4)

Suppose you enter "Mozilla Firefox" in the search field, where the blinking cursor is in the middle of the word "Firefox" like Mozilla Fire|Fox, and the compose of the word is compete, i.e. there's no underline for spell correction, etc. Under this circumstances, you can select "Mozilla" by long pressing on it, but you cannot select "Firefox".

Yes. I see this behavior. Neither long pressing or double tapping "Fire|fox" (with the cursor) will select the word "Firefox" in Fennec or Fenix. In Chrome, long pressing or double tapping "Fire|fox" (with the cursor) does select the word, though the behavior seems to be inconsistent, especially for words that are not the last word (so trying to select "Mozilla" with the cursor instead of "Firefox").

We always extend the touch area regardless whether there is a selection range or not. If we'd like to exclude the touch area that cover the text when there's only a blinking cursor, which means we want to priorize selecting a new word over dragging the caret, I maybe can investigate how to do it.

@ Vesta, given the usability trade-offs mentioned by Ting-Yu, I don't know what the expected behavior should be. Perhaps a Fenix UX designer should evaluate Gecko's and Chrome's behavior and make a recommendation.

Comment 6

[vzare]

Thanks Chris. I think it's ok if user can't long press to select a word as long as there is another way to do that. In both Chrome and Fennec, user is able to "select all" and then use the selection handler to narrow down the selection but in Fenix the context menu covers the text so user is not able to see or move the selection handler.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Chris Peterson [:cpeterson]]

(In reply to vzare from comment #6)

I think it's ok if user can't long press to select a word as long as there is another way to do that. In both Chrome and Fennec, user is able to "select all" and then use the selection handler to narrow down the selection but in Fenix the context menu covers the text so user is not able to see or move the selection handler.

Vesta, so you're saying the current Fenix behavior is not OK since the Fenix context menu covers the text and prevents the user from using the using the selection handler? It would have been OK "as long as there is another way to do [select a word]", but it sounds like there isn't another way.

In that case, this bug should probably have a higher priority than P5.

Comment 9

[vzare]

Yes that's right :)

Comment 10

[Chris Peterson [:cpeterson]]

In that case, I will clear the priority so Layout triage will consider giving this bug a higher priority. This is a bug for the Gecko Layout team, not the GeckoView team.

Comment 11

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

I cannot find an existing bug describing the context menu covering the blue caret, so I filed bug 1587921.

Note that the positition of the context menu is controlled by the front-end code, AccessibleCaret only prepares the current selection's boundingClientRect, and fires the event whenever the selection range is changed.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: Screenshot of Fenix on dholbert's phone

Comment 13

[Daniel Holbert [:dholbert]]

Fenix on my phone sometimes does not reproduce the bug... Comment 12 has a screenshot of what I see when I perform the STR and long-press a word. Other times, though, I do notice that the long-press seems to have no effect, besides just spawning a "Paste|Select all" menu -- but even when that happens, I don't personally see overlap. The menu ends up below the AccessibleCaret, similar to the screenshot in comment 12. So the user can still choose "Select All" and then narrow the selection, which it sounds like we're OK with per comment 6.

Maybe this is something that was fixed in Fenix recently which is why I'm seeing better behavior? Or maybe there's a dependency on hardware/OS? (I'm using a Pixel 3 running Android Q, and I'm using the Fenix nightly-channel [i.e. the "beta" channel on the play store])

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Daniel Holbert [:dholbert]]

(Sorry - when I was testing in comment 13, I'd missed the "if the cursor is already in the word" requirement. That's why long-pressing was working for me, I think.)

Let me try sum up the current state of this bug. There are two separate issues here:

1. Long-pressing-to-select-a-word does not work, if the AccessibleCaret cursor is nearby, because we expand the AccessibleCaret hit-box a lot.
2. For some people (not me), the context menu (shown for double-tap and also for selection) covers up the text & AccessibleCaret (bug 1587921).

Per comment 8-9, it sounds like we're kind of OK with issue #1 (not a blocker), since it can be worked around, but issue #2 (bug 1587921) breaks the workaround, for users who are affected by that issue (not me).

Also: per comment 11, the placement of the context menu is controlled by frontend code, so issue #2 (bug 1587921) isn't a core-layout bug.

Conclusions:

• It's ~high priority that we fix at least one of this bug here & bug 1587921
• bug 1587921 seems like a pretty big usability issue for context-menu usage in general (for affected users), so I tend to think that one is high-priority just on its own merits
• this bug here is probably ~P3, though if we can't do anything about bug 1587921 for some reason, then maybe this is higher-priority (depending on how many users are affected by bug 1587921 and hence can't work around this bug).

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Chris Peterson [:cpeterson] from comment #0)

STR

1. Open Wikipedia: https://en.m.wikipedia.org.
2. Enter some words in the "Search Wikipedia" text field.
3. Try to select an individual word by long pressing it or double tapping it.

FWIW: long-pressing seems to work for me & svoisen, in current Fenix Nightly. (You do kind-of need to long-press the top half of the word -- if you're too low, it may move the cursor instead.) So that part feels like it's basically fixed, to us at least...

Double-tapping still does not seem to work, though -- it brings up a [Paste|Select all] context-menu instead of selecting the double-tapped word.

Comment 18

[Daniel Holbert [:dholbert]]

cpeterson, can you still reproduce the long-pressing issue? (see comment 16 and comment 15)

Comment 19

[Chris Peterson [:cpeterson]]

(In reply to Daniel Holbert [:dholbert] from comment #18)

cpeterson, can you still reproduce the long-pressing issue? (see comment 16 and comment 15)

WFM in Firefox 88 and Nightly 90.