1933626 - textarea caret disappears on double-click

Status: NEW

(Core :: DOM: Selection, defect)

Description

[Gary]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0
Firefox for Android

Steps to reproduce:

Given this textarea:

<textarea style="white-space-collapse: collapse"></textarea>

Double click on the textarea (ie, click twice in <500ms, without moving the cursor).

Actual results:

The caret in the text area jumps from the left side of the textarea, to the right side.

Expected results:

The caret should stay on the left side.

Comment 1

[Gary]

I've tested this in Chrome 131.0.6778.86 and Safari 18.1.1, neither of them exhibit the same behaviour. I haven't been able to test on other platforms.

Comment 2

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

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

Comment 3

[Alice0775 White]

There are several changes (regressions) going back.

1st regression :
Good build : The caret is staying at the left as expected
Latter build : Caret disappear
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0c03de83f9a8235eb0eeb2ba04fab41cb302cb52&tochange=c629f163190c742aa083608e0805b257f51e4539
Suspect: Bug 1713334

2nd regression :
Former build : Caret disappear
Latter build : Caret move to the right
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=97b5cf7504be3be23cfe6a762a5a02fd27a49673&tochange=677bc5b3f7e679611868078e420607385d4ca20e
Suspect: Bug 1852478

3rd regression :
Former build : Caret move to right
Latter build : Caret disappear
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b012c483a27589fcc3a63422fe2e619d025af606&tochange=53711e5bca1a324c5ca26bddc9a0d58920259942
Suspect: Bug 1905904

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Bug 1905904 made this behave like a regular textarea right?

Comment 5

[Alice0775 White]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Bug 1905904 made this behave like a regular textarea right?

Yes. it does.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

So to the extent there's something to fix here, the fix is making the caret not disappear when double-clicking a textarea. And that was regressed by bug 1713334 afaict.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Kagami, any chance you could take a look? I don't think it's super-prioritary tho, comment 0 is fixed by bug 1905904.

Comment 8

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

Set release status flags based on info from the regressing bug 1713334

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

I'm on PTO and I've been away from the selection code for years; at this point probably :masayuki knows far better.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

I guess that double/triple click creates non-collapsed range in the anonymous subtree. PeekOffset should not extend the range outside the text node in the anonymous <div>. Unfortunately, I don't have much time to work on this for now. Jan, how about you?

Comment 11

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Jan and I talked about this, and I will work with him to add this into his queue.

Comment 12

[Jan Jaeschke [:jjaschke]]

This behavior seems to occur regardless of the white-space or white-space-collapse value. At least I can also see it here:

data:text/html,<textarea></textarea>

I've skimmed through the pernosco recording and as Masayuki pointed out the range is indeed not collapsed, because there are actually two nodes: an empty text node, and a br node. And the range goes from parent offset 0 to offset 1, therefore is not collapsed.
If I hardcode this to collapse the range (I just did a build where I compiled the offset = 0 into the code), the caret is visible again.

Masayuki, does it make sense to look at this condition in nsIFrame::PeekOffsetForWord()? This feels like the right place.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

I'm not sure your selected lines are exactly where we need to touch, but yes, I think we need to touch the method and/or callees.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

It seems that the root cause is same as bug 1946001.