1925606 - Ctrl+Backspace in Gmail email composer deletes the last word *and space character* (though the cursor shows up after space character until you start typing)

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Compose a new email in Gmail.
2. Type abc def into the email body.
3. On Linux/Windows, hold Ctrl and press Backspace. Or on macOS, hold "option" and press Backspace. Note that the "def" disappears and the cursor is now shown after the space character, looking like abc |
4. Now type another character (e.g. g)

EXPECTED RESULTS:
The g should be inserted after the space (where the cursor was), so you should end up seeing abc g

ACTUAL RESULTS:
The space disappears, so you end up seeing abcg

I'm using Ubuntu 24.10.
Chrome gives EXPECTED RESULTS.
Firefox 133.0a1 (2024-10-17) (64-bit) gives ACTUAL RESULTS.

(This is a longstanding bug, I think; not sure if it's been reported before, but I'm not finding anything when searching bugzilla for "ctrl backspace gmail"; hence, filing.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of STR, showing the bug

Comment 2

[Daniel Holbert [:dholbert]]

Still reproduces if I activate Chrome mask, so this probably is not a UA-sniffing issue. There may be an actual platform difference of some sort, or something where Gmail is taking different codepaths based on some browser-specific feature other than the UA string.

Comment 3

[Daniel Holbert [:dholbert]]

If I take a look at the relevant node in devtools, I can see that Firefox ends up with the following, with a trailing space character:

<div class="gmail_default" style="font-family:arial,sans-serif">abc </div>

(we don't show the trailing space visually in DevTools, but it's there if I do right-click | edit-as-html)

...whereas Chrome ends up with a  :

<div class="gmail_default" style="font-family:arial,sans-serif">abc&nbsp;</div>

If I use devtools to swap out our space for a   (what Chrome has there), then I end up getting EXPECTED RESULTS.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screencast of the bug with devtools open to show the contents of the node-in-question

Comment 5

[Daniel Holbert [:dholbert]]

This isn't reproducible in some of my systems/Firefox-profiles, so there might be some A/B testing involved here with different experiences being served some of the time.

So far, I've always been able to reproduce in a fresh profile (repro'd in a fresh profile on Ubuntu 24.10 on two different machines, and in macOS on another machine).

In the existing profiles that I have where the bug-does-not-reproduce, the thing that seems to save me is a <br> element that persists at the very end of the <div class="gmail_default"> element for whatever reason. That <br> stays there when I delete the "def" text in step 3 (it ends up immediately after the space character), and it seems to ensure that the space stays there when I type my "g" in step 4.

Comment 6

[Daniel Holbert [:dholbert]]

Turns out this is quite-easy to repro with just a simple contenteditable div; I spun off bug 1925635 as the underlying platform bug here.

Comment 7

[:glob ✱]

This also impacts comments in Google Docs (not the main doc content, just comments).

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to :glob ✱ from comment #7)

This also impacts comments in Google Docs

Overholt filed bug 1926087 on that; we can consider it a distinct webcompat site-report for now (with the same underlying platform bug).

(I'm pretty sure I've tripped over this in Google Calendar event-description-text, too.)

Comment 9

[Andrew Overholt [:overholt]]

I see this in the Fastmail composer, too, FWIW.

Comment 10

[Daniel Holbert [:dholbert]]

This turned out to have been partly-caused by the patches that landed in bug 1923251. Masayuki and I backed that out earlier today, which will probably make this no-longer-reproducible in tomorrow's nightly, hopefully.

(bug 1923251 is what turned out to be responsible for deleting the all-important <br> element that I referenced in comment 5. At the time I wrote comment 5, I thought my "good" sessions (where the <br> persisted and propped up its neighboring space character) were a result of some Gmail A/B testing, but in fact I'm pretty sure those "good" sessions were just environments where I was running a slightly-out-of-date nightly.)