1917322 - inconsistent behavior of the Selection object when used from INPUT element

Status: UNCONFIRMED

(Core :: DOM: Selection, defect)

Description

[[:jaborandi]]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Steps to reproduce:

1. go to https://ewnjtgouierg.github.io/ffbugs/SelectionFromInputFieldInconsistency.html

2. press Enter

3. click inside the INPUT field and press Enter

4. click on the page outside of the INPUT field then click inside the INPUT field, then press Enter

Actual results:

2. word THIS is selected

3. word THIS is selected

4. word THIS is NOT selected

Expected results:

word THIS should be selected in all cases. or at the very least it should behave equally in 3 and 4

apparently, if you focus somewhere outside of the INPUT field and then give focus to INPUT field - then adding an arbitrary range to the Selection object doesn't work WITHOUT taking focus away from the INPUT field first: if you check the "blur before select" checkbox, selection will work on step 4 too

Comment 1

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

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

Comment 2

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

Hey Sean, this looks suspiciously related with other focus management bugs you're fixing. Thoughts?

Comment 3

[Tom S. (please needinfo tschuster)]

Maybe bug 85686 or bug 1527627?

Comment 4

[Sean Feng [:sefeng211]]

This isn't strictly the same, but I think this also relates to how we design the selection with <input>...

Once we do click on the page outside of the INPUT field then click inside the INPUT field, then press Enter, the nsFrameSelection for the PresShell is hidden, because the <input> has a different nsFrameSelection. And we don't paint the selection background for hidden selections.

The nsFrameSelection are queried at https://searchfox.org/mozilla-central/rev/181e5bb2645236a617d42e3740420098097f7a0f/layout/generic/nsIFrame.cpp#4728

Masayuki, I don't know the original idea, but I believe there are reasons for the input to have a different nsFrameSelection? Thoughts for this?

Comment 5

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

Yeah, we basically don't move focus changing selection. Therefore, in the step #4, <input> keeps having focus and the normal selection outside it keeps invisible. (I think Selection API will return what web apps expected as-is even in the case, the range should be just invisible.)

Only the exception is, we started move focus to the innermost editing host of selection range when selection was outside it for compatibility with the other browsers. So, it might be better to align the behavior to the other browsers. However, in Chrome, the <input> keeps being rendered as focused but typing text won't be accepted. I think this is really bad design from a11y point of view. So, unless we have actual web-compat issues, we should not change our clearer behavior...

(Web apps can same thing with a <input>.blur() call.)

Comment 6

[Sean Feng [:sefeng211]]

Thanks Masayuki, so I see we already have a few issues webcompat issues around the design of each text control have independent selection objects. Is it particularly bad if we stop doing it? Is it for better a11y support, and if so can we have one selection while also persist the a11y design?

Comment 7

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

I think that updating Selection of the page should not cause changing focus when a text control has focus because it's done by script, the user may not intended. So, the reported expectation may make users confused. On the other hand, web apps can do it with calling <input>.blur() even on Gecko. So, doing <input>.blur() from Selection::NotifySelectionListeners() may be reasonable. On the other hand, if we actually move focus from focused <input>, the behavior is also different from Chrome (looks like that Chrome keeps focusing on <input>, just the <input> stop handling text input). E.g., Tab after Enter in the testcase make the following checkbox focused rather than the <input> immediately after selected text. So, fixing this could cause another web-compat issue.

(I think that we should file a bug of Chromium at least for that <input> stop handling text input even though it keeps having focus.)

Comment 8

[Sean Feng [:sefeng211]]

I see.

Do you think there's still a bug in our code such that the selection is visible for #step 2, but not visible for #step 4? Shouldn't they be consistent?

I think if we make the above consistent, the only difference between us and Chrome/Safari is that we all have the <input> remain focused when a selection is made, but they stop handling the text input and we still do. Then we can discuss this from the spec level, what do you think Masayuki?

Comment 9

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

Ah, I see the point. Yeah, the result of #3 and #4 should be consistent and in the both cases, selection outside <input> should be hidden.
https://searchfox.org/mozilla-central/rev/fc327076fbb7290a8ce4e713dce82cc744681cd4/layout/base/PresShell.cpp#1606

Comment 10

[Sean Feng [:sefeng211]]

FWIW, Safari also doesn't focus the selection in step #4, so Firefox and Safari are the same.