Double click or long press in text input padding do not select the nearby word
Categories
(Core :: DOM: Selection, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox162 | --- | fixed |
People
(Reporter: csalinezh, Assigned: csalinezh)
Details
Attachments
(1 file, 1 external file, 1 obsolete file)
|
1.86 KB,
text/html
|
Details |
Steps to reproduce
- Open the attached text-control-selection-repro.html (LLM-generated)
- On desktop, double click the area outside the text rows. On touchscreens, try double tap and long press around the text rows. Pay attention to
Actual results
The word is selected only when the pointer falls on it. If it falls on the padding (no matter how small the offset it), double clicking only moves the cursor and does not select the word. Double tapping or long pressing may move the cursor to the beginning of the input text box.
Expected results
At least for the single line <input> text box, it makes sense to allow such cases to select the nearby word. It is less relevant for mouse input, but on touchscreens it should reduce confusion on the behaviour of double tapping and long pressing. Even with mouse, it feels weird that double clicking in the padding does not select the word, when the cursor has already turned into the text input one.
Chromium and Android native text controls allow events falling on the padding to trigger these behaviours.
MoveCaretToEventPoint resolves single clicks with only SKIP_HIDDEN,
whereas SelectByTypeAtPoint also sets IGNORE_NATIVE_ANONYMOUS_SUBTREE,
preventing selection from reaching the editor through control padding.
IGNORE_NATIVE_ANONYMOUS_SUBTREE was added for bug 1872302 so that moving
the document's caret up or down a line can't enter text controls.
Targets within a text control use that control's independent selection,
where the editor's content belongs. Use the single-click flag for those
targets so double clicks select words using the same point resolution as
single clicks.
|
||
Updated•13 days ago
|
A long press in a text control's padding, empty area or line leading
could select no word and show the Paste menu at the previous caret.
Resolve such presses in the editor with the single-click flags, so that
line boundaries, wrapped lines and writing modes behave as for a click,
and select the word when the press is beside its text only in the block
axis.
Bug 1448730's caret/Paste menu fallback still applies beside the text
along the line, and where browser.drag_out_of_frame_style=1 (the default
on Android, macOS and Linux) resolves a press above or below the text to
its start or end, which ContentOffsets::isAtFrameEdge now exposes. Note
that Android TextView would select the word nearest to the finger; while
this keeps a long press where a tap at the same point puts the caret.
|
|
||
Updated•12 days ago
|
|
|
||
Updated•12 days ago
|
|
||
Comment 6•5 days ago
|
||
Backed out for causing wpt failures @text-control-multiclick-around-text.html.
|
||
Comment 8•4 days ago
|
||
| bugherder | ||
Tested Nightly 162 (20261105205004) on Android. Double tap finally works in text controls. The landed patch does not change the long press behaviour much.
The android port has been using browser.drag_out_of_frame_style=1 since bug 568700, probably because the config was copied from the Linux one without deliberation. However, the native text control and Chrome's behaviour seems to be style 0. I prefer style 1 personally, but this config might be worthwhile to change if someone think it should match native Android.
Description
•