1985376 - www.google.com - Pressing [Delete] key only deletes the first letter of search term, and caret jumps to the end of the term

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Alice0775 White]

Steps to reproduce:

1. Open www.google.com
2. Search something with the Google e.g., firefox + [Enter]
3. Tabbing to navigate to the input field of the google
4. Press [Delete] key twice

Actual results:
only delete a fist letter of search term, and caret jumps at last of the term
i.e., irefox| (here, | indicates text caret)

Screencast: https://youtu.be/N1loeF8hN5s

Expected results:
The Delete key functions correctly.
i.e., deleting two letters and placing the text cursor before the first letter.
|refox

Google chrome 139.0.7258.139 works as expected.

Comment 1

[Alice0775 White]

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=d4b71143f9a7937e24bf57f9fb56f1bf414b55c0&tochange=4fcd1b02c5bdfdb3d4e9b8d8b93289f81c638981

Suspect: Bug 1725973

Tentatively, mark Bug 1725973 as a regressor.

Comment 2

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

:TYLin, since you are the author of the regressor, bug 1725973, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Alice0775 White]

Workaround:
The issue seems to be resolved by applying display: block instead of display: flex to the .gLFyf (class of the relevant textarea).

.gLFyf {
  display: block !important; /* instead of flex;*/
}

Comment 4

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

Hmm, it's a <textarea>, why its layout affects to the result of Selection at typing Delete...?

Comment 5

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

I can reproduce this with the steps in comment 0.

However, if I change step 3 from "Tabbing to the Google search input field" to "Clicking at the beginning of the input field," I cannot reproduce.

A reduced testcase would be helpful for debugging.

Comment 6

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

Moving to the same component as the one of the regressor bug.

Comment 7

[Jonathan Kew [:jfkthame]]

I see similar behavior with slightly different STR (as I don't have a forward-delete key on this MacBook keyboard...): after tabbing to navigate to the input field, press right-arrow to move the cursor forward by one letter, then press backspace to delete the first letter; the caret jumps to the end of the text.

However, if I press right-arrow twice before doing the backspace, so that the character being deleted is not the first letter in the input field, the bug doesn't occur. But if I do shift-right-arrow to select (instead of stepping over) the first two characters, and then press backspace to delete them, the bug does happen.

I suspect this might be related to the exact DOM node/offset position we think the selection is at, when it's at the beginning of that input field; we may be setting it differently depending whether we arrived there by mouse-click or by tabbing to the field.

Comment 8

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

The shift-arrow to select on flexbox reminds of bug 1792333, where we implemented nsILineIterator interface for selecting the frame.

Comment 9

[Daniel Holbert [:dholbert]]

Notably, after you press "del" for the first time, the page layout changes to open the dropdown-menu. (That's what happens if you manually click the editable area, too.)

Given the regressor, I'm assuming that the problem has something to do with that layout change - it must end up invalidating the caret-position somehow.

Comment 10

[Daniel Holbert [:dholbert]]

I'll try to capture this in pernosco tomorrow for further diagnosis/analysis.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Alice0775 White from comment #3)

Workaround:
The issue seems to be resolved by applying display: block instead of display: flex to the .gLFyf (class of the relevant textarea).

.gLFyf {
  display: block !important; /* instead of flex;*/
}

This^ doesn't help for me. Maybe Google changed their styles here? Or maybe this^ was done using DevTools which happened to work around the bug for unrelated reasons (e.g. the field being focused at the right time which caused Google to add/remove styles)?

I did find a different workaround though -- the following (applied in e.g. Stylus) does work around the bug for me:

textarea.gLFyf {
    white-space: pre-line;
}

The issue seems to be that:
(1) When you start to interact with the textarea (when you press "Del" in the STR), Google adds class "sbfc" to some ancestor element, and that causes a new style rule to apply, which changes the textarea from white-space: nowrap to white-space: pre-line
(2) That style change causes nsStyleText::CalcDifference() to declare that we need to reconstruct the textarea's frame, because WhiteSpaceOrNewlineIsSignificant() changes its answer.
(3) So we reconstruct the text frame, and we end up moving the caret to the end as part of that, roughly here I think (as part of a PrepareEditorEvent fired by TextControlState::BindToFrame when we create the new frame):
https://searchfox.org/firefox-main/rev/dc1c78e9c37aba6ed05a4ec47c4bfcb16f57b51d/editor/libeditor/EditorBase.cpp#3704

CollapseSelectionTo(EditorRawDOMPoint(&aTextNode, aString.Length()), error);

We manage to avoid that if the caret is in the middle of the string, though - I recall that we save caret/selection state across frame-reconstruction in some way, which must be working if the caret is in the middle but not at the start.

I've got a reduced testcase which I'll spin off as a platform bug here.

Comment 12

[Daniel Holbert [:dholbert]]

Filed bug 1993351 as a platform-bug, with a testcase.

Comment 13

[Daniel Holbert [:dholbert]]

Alice0775 White: could you see whether you're still getting the same regression window as noted in comment 1?

I get an older regression range -- with this bug's STR, I get the same regression range that I just shared in bug 1993351 comment 4, which is:
INFO: Last good revision: 7a6d6b986a1ed263db6d19ecbd56e2f4210870cf (2020-12-10)
INFO: First bad revision: 1130661c79c222fb1acd29b7ec5dc5202cdd0d2d (2020-12-11)
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7a6d6b986a1ed263db6d19ecbd56e2f4210870cf&tochange=1130661c79c222fb1acd29b7ec5dc5202cdd0d2d
...which points to bug 1681615 as the regressor here.

(If we're still getting different regression ranges, then I wonder if you're getting a different version of google.com styles than I am, though. Or maybe Google's styles have changed in the weeks since you posted comment 1.)

Comment 14

[Alice0775 White]

Yes, like you, I got the following range.
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=ac54ee8d90e5ce166dd231574d98382fba7316b4&tochange=3652d2a382005d6c6755405734168ddeca937ff4

And the workaround css in Comment#3 does not help any more. I don't know why.

Comment 15

[Daniel Holbert [:dholbert]]

OK, great - thanks for checking/confirming!

(also: nice, your regression range is narrower than mine, and still contains the commit for Bug 1681615. So that adds some confidence in that bug being the regressor, unless anyone sees reason to suspect another commit in there.)

Comment 16

[Daniel Holbert [:dholbert]]

This is FIXED in current Nightly 146.0a1 (2025-10-20), by bug 1993351.

I tested Nightlies before/after bug 1993351's fix to confirm that that's what did it.

Nightly 2025-10-16 is "bad"
Nightly 2025-10-17 is "good"

Comment 17

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.