1925635 - Space character disappears from contenteditable, when typing after doing Ctrl+Backspace (or option+Backspace) to delete a word

Status: ASSIGNED

(Core :: DOM: Editor, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.
2. Click after def in the editable area.
3. Ctrl+Backspace to delete def.
4. Type g

EXPECTED RESULTS:
abc g

ACTUAL RESULTS:
abcg (no space)

This affects Gmail's email composer -- tracked in bug 1925606 -- and makes it pretty painful to type emails if you've got Ctrl+backspace as part of your muscle-memory for editing (as I do). Though in some cases you might manage to avoid it, possibly due to some Gmail A/B testing, per bug 1925606 comment 5.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 2

[Daniel Holbert [:dholbert]]

This is not a regression; I can reproduce as far back as 2009-12-31.

Chromium and WebKit seem to avoid this by replacing the trailing space with   when I do Ctrl+Backspace to delete the "def" text.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (to demonstrate   being swapped in for the space character in other browsers)

Chromium and WebKit seem to avoid this by replacing the trailing space with   when I do Ctrl+Backspace to delete the "def" text.

Here's a testcase to demonstrate this. If I do Ctrl+backspace to delete the "def" text, and then click the button: Chromium and WebKit both show <div>abc&nbsp;</div>, whereas Firefox shows <div>abc </div>

(Also: using this testcase in Firefox, if I simply press backspace 3 times instead of doing Ctrl+Backspace, then we give expected-results, and the button reveals that we've got this innerHTML with a trailing br element: <div>abc <br></div> and that trailing <br> seems to be sufficient to avoid this bug, probably because it prevents the whitespace from being at the very end of the element. Maybe we should be consistent about inserting that <br> when the user does Ctrl+backspace, too?)

Comment 4

[Daniel Holbert [:dholbert]]

ni=masayuki as the expert on editor code -- masayuki, I wonder if this is a known issue and/or if there's anything that can be done easily here, particularly given that this affects Gmail. Thanks!

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: semi-reference-case for testcase 1

Here's a sort-of-reference-case for testcase 1, where this works as-expected, one time at least.

I've just added a <br> element up-front, which is how Gmail manages to avoid tripping this bug in some of my Firefox profiles per bug 1925606 comment 5.

(However: in this reference case, we delete that <br> as soon as you start typing new characters into the textfield, so it's not a persistent fix here. Maybe gmail had a hackaround that made it persist somehow -- whether intentionally or unintentionally -- not sure.)

Comment 6

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

Oh, it looks like a bug of both layout and editor. I think that layout should not render the trailing white-space if it's collapsible even in editable text node. On the other hand, editor should insert a <br> when it becomes invisible.

(I think probably I filed the layout bug because I remember this issue.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

Created attachment 9432321 [details]
semi-reference-case for testcase 1
[...]
(However: in this reference case, we delete that <br> as soon as you start typing new characters into the textfield, so it's not a persistent fix here. Maybe gmail had a hackaround that made it persist somehow -- whether intentionally or unintentionally -- not sure.)

Aha! This "we delete that <br>" behavior seems to be a recent behavior-change, I think from bug 1925606 [EDIT: copypaste typo -- I meant "I think from bug 1923251".] So that's why we're starting to notice this issue a bit more on real-world web properties.

It sounds like that was an intended behavior-change, based on the part-2 commit message over there ("Make HTMLEditor clean up unnecessary padding line breaks when deleting something immediately before it"). But I suspect we didn't realize that these line breaks had a useful benefit in some cases, as they did in e.g. Gmail here.