1938110 - Space character being deleted in Gmail composer

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P1)

Description

[Andrew Overholt [:overholt]]

STR

1. (I'm using a 2024-12-16 Nightly as I file this and will restart to see if it still reproduces) open the Gmail composer
2. type 'how are you doing' and notice that it offers to complete with the question mark
3. rather than pressing Tab or typing ?, type space

Expected

• you get a space

Actual

• no space character is there

Comment 1

[Andrew Overholt [:overholt]]

I can still reproduce with a 2024-12-18 Nightly.

Comment 2

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

Hmm, when I type a white-space, a <br> does not appear after that. However, I cannot reproduce this bug with a simple testcase.

I'll check what occurs within a debug build.

Comment 3

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

Hmm, it could be both bugs of ours and theirs. When I type first white-space when there is ? [tab], we cannot put <br> after the typed white-space since it's followed by ? [tab]. However, after that, there are a lot of empty text nodes after the caret. It seems that that causes our white-space scanner confusing. I try to fix the latter today. Then, let's check the former would still be reproducible.

Comment 4

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

Ah, the latter is a very minor bug of inserting white-space at invisible trailing white-space at end of the block... Well, I'll try to put <br> by the mutation by the web app.

Comment 5

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

Okay, I succeeded to hack. I'll post a patch.

Comment 6

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

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

Comment 7

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

Attachment: Bug 1938110 - Make `HTMLEditor` keep the last typed collapsible white-space visible even after mutations by web apps r=m_kato!

Gmail composer puts non-editable <span> to show a suggestion to make
autocomplete feature available. Then, if user types a white-space, Gmail
composer replaces or deletes the non-editable <span>.

When user types a white-space before the non-editable <span>, our editor does
not think that <br> is required to make the white-space visible because of
the following non-editable text. However, it'll be removed asynchronously.
Then, the white-space becomes invisible trailing white-space of the block and
Selection is collapsed after it. Therefore, following editing behaves odd
because our editor does not handle correctly editing in invisible white-spaces.

As you know, Gecko is the only browser to use the ASCII space (U+0020) as a
trailing collapsible white-space immediately before a block boundary.
Therefore, web apps may implement this feature with similar approach without
taking care of Gecko. Therefore, we should use a hack for our uses.

Fortunately, this may occurs only when user appends a collapsible white-space
to end of a Text node. Therefore, HTMLEditor can cache the last Text
node whose last character is recently appended collapsible white-space.
Then, when our mutation observer detects that the white-space becomes invisible,
the mutation observer can put a padding <br> element.

Unfortunately, the <br> is put with the transaction. Therefore, undoing it
deletes only the padding <br> and does not delete the white-space. However,
it's hard to touch transaction management right now. Therefore, this patch
does not fix this issue.

Depends on D231197

Comment 8

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

Makoto-san, could you review this first rather than the other patches for the editor module? Thanks!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ec81b9013110
Make `HTMLEditor` keep the last typed collapsible white-space visible even after mutations by web apps r=m_kato

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/49794 for changes under testing/web-platform/tests

Comment 11

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

The bug is marked as tracked for firefox135 (nightly). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 12

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

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #11)

The bug is marked as tracked for firefox135 (nightly). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

I trusted the setting from Masayuki and we give this P1 to reflect the urgency of landing this.

Comment 13

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/ec81b9013110

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 15

[Bogdan Maris, Desktop Test Engineering [OOO until Dec 16th]]

Reproduced the issue described in comment 0 using an old Nightly build from 2024-12-16, verified that using latest Firefox 135.0b8 build across platforms (Windows 11, macOS 13 and Ubuntu 22.04) this is no longer an issue.