1448730 - After a longpress in an input or textarea, Firefox Android selects the previous word even when there's a space

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect, P1)

Description

[Karl Dubost💡 :karlcow]

This is a spin-off of https://webcompat.com/issues/15953

The initial bug report
======================
STR:
0. Prerequisite: have something in your clipboard, that you want to paste
1. start a new tweet (either replying or with a brand new tweet)
2. write a word, either followed or not followed by a space. The cursor will be after the space.
3. Longpress in the empty space at the right of the word
=> The space and the previous word are selected, and the context menu with "paste" appears. As a result, when pasting, the previous word is replaced too, which is unexpected with this flow.

The behavior is correct in Chrome (eg: the word isn't selected unless we longpress on the word itself).

I initially thought this would happen in Twitter only but actually this happens everywhere there's an input (either input text, or textarea). But this is especially painful in Twitter where it's common that we want to paste something. The workaround is to start a new word that will get replaced.
======================


The key in the initial bug report: "This happens everywhere"
And indeed I tried with just 

https://codepen.io/webcompat/pen/ZxXKxr

And I could reproduce.


Chrome is handling in a more elegant way probably. Is there something which prevents us to make this part of the UX more seamless.

Comment 1

[Makoto Kato [:m_kato]]

I don't like current longtap behavior, and I think that Chrome's way is better. Although this issue is accessibility caret, I take this.

Comment 2

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 3

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 4

[Chris Peterson [:cpeterson]]

A similar bug was reported in the Fenix issue tracker: https://github.com/mozilla-mobile/fenix/issues/2860

Comment 5

[Chris Peterson [:cpeterson]]

Adding [geckoview:fenix:m8] whiteboard tag because Makoto says he will work on this bug in Q3.

Comment 6

[Chris Peterson [:cpeterson]]

Moving to the GeckoView Bugzilla component.

Comment 7

[Chris Peterson [:cpeterson]]

dbolter said he'd like to see this bug fixed in Q3.

Comment 8

[Chris Peterson [:cpeterson]]

Adding this bug to GV's September sprint.

Comment 9

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=348e236c8fe4d12dff8e1a6c70f2962476b4164e

Comment 10

[Makoto Kato [:m_kato]]

Attachment: Bug 1448730 - Long tap doesn't select word if tapped point isn't text.

Actually, Gecko's long tap implementation will select a word string near tapped area even if tapped area isn't text. But even if it is white space only, not word, we select white space.

Since Blink doesn't select it and user reports this issue via web compat, I would not like to select white space only text if tapped area isn't text.

If tapped point is on white space text, it keeps original behaviour that selects white space.

Comment 11

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

In general, I think this is a good improvement because people like to long tap to show the context menu all the time. An alternative way to force show the context menu is:

1. Single tap at the empty area, and the blue caret should show at where the blinking cursor is.
2. Tap on the blue caret, the context menu will show.

This also works on Google Chrome.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dd1ab53baf97
Long tap doesn't select word if tapped point isn't text. r=TYLin

Comment 14

[Stefan Hindli [:stefan_hindli]]

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