1961521 - In contenteditable, typing a Compose sequence after whitespace shifts it to before the whitespace

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Chris Morgan]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:139.0) Gecko/20100101 Firefox/139.0

Steps to reproduce:

1. Prerequisite: have a Compose key set up.
2. Open data:text/html,<div contenteditable autofocus>A </div>.
3. Place the cursor at the end of the line, after the space.
4. Type Compose < " (for “).

Actual results:

During composition, you get an underlined · and then \<, in the correct location, as is traditional.

But after composition finishes, when the “ is placed, it (and the cursor) are shifted before the whitespace, so that you get A“|, rather than A “| (| indicating the caret position).

Expected results:

It should have stayed where it was.

This applies to any whitespace sequence at any position. Type a dozen spaces and put the cursor anywhere in it, and the compose sequence and cursor will be shifted to before them all.

Bisecting revealed bug 1951832 as the regressor, but it just enabled the editor.white_space_normalization.blink_compatible pref, so I don’t know if you count it or something else as the regressor.

Disabling editor.white_space_normalization.blink_compatible restores the old behaviour. I’ll keep it so for now, because it’s rather debilitating for my typing style!

Comment 1

[Chris Morgan]

Minor fix of something in the description, where annoying Markdown quirks mangled it (I really should have used a non-breaking space the first time as a precaution against such stupidity, even though it’s kinda wrong then):

But after composition finishes, when the “ is placed, it (and the cursor) are shifted before the whitespace, so that you get A“|, rather than A “| (| indicating the caret position).

A“| should be A“| ; the space is still there, just after.

Comment 2

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

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

For more information, please visit BugBot documentation.

Comment 3

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

The white-space should be invisible because of immediately before the end block boundary of the <div contenteditable>. Therefore, the white-space should be deleted at modifying end of the <div> for making the further processing simpler and such behavior is almost same as the other browsers (although it may be different whether the invisible white-space is deleted in each case). Additionally, anyway the white-space won't appear as the last white-space on the web apps after you save the content and load it.

So, from the editor module point of view, this is a WONTFIX bug for now even though the behavior looks completely odd.

Comment 4

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

In other words, this is unrealistic case in usual web apps because the invisible white-spaces should be trimmed by the web app when the content gets loaded to avoid odd behavior on any browsers.

Comment 5

[Chris Morgan]

No, this happens at any place in the contenteditable: the compose sequence and final cursor position are shifted to the start of any sequence of spaces. This is what makes it really bad for people like me who type curly quotes.

Type He said “hello”. using a Compose sequence for the curly quotes, and you get He said“hello”.|  instead of He said “hello”.|

Type Alpha          Beta, place your cursor in the middle of the spaces, and type Compose o o, and instead of Alpha     °|     Beta, you get Alpha°|          Beta.

(Aside: ugh, what is this Markdown engine doing, collapsing multiple spaces inside backticks!?)

Comment 6

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

So, do you say it's reproducible with data:text/html,<div contenteditable autofocus>A%A0</div>?

Comment 7

[Chris Morgan]

Yes. Any spaces, including non-breaking ones, in any position.

Comment 8

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

Okay I reproduce this on Ubuntu.

Comment 9

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

Oh, this is really tricky behavior of the IME.

When I type the last character, the composition ended with empty string temporarily. Then, keydown is fired again and it introduces the composed character as usual typed text.

Comment 10

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

Attachment: Bug 1961521 - Make `HTMLEditor::HandleInsertText()` collapse `Selection` properly after deleting composition r=m_kato!

When inserting text or deleting text is for updating composition string,
InsertTextWithTransaction() does not suggest caret position because in the
most cases, CompositionTransaction updating Selection properly. However,
if it's deleting existing composition (i.e., replacing the composition with
empty string), HTMLEditor::HandleInsertText() doesn't use
CompositionTransaction to update composition. Instead, it uses the suggested
caret position from InsertTextWithTransaction() even though it's always unset.
Therefore, if the composition string follows some collapsible white-spaces and
they are replaced, Selection is automatically moved to the start position of
the replaced range and HTMLEditor::HandleInsertText() does not maintain the
caret position.

Therefore, this patch make it collapse Selection to end of the inserted text
where the composition string was.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/855263bb7dd2
Make `HTMLEditor::HandleInsertText()` collapse `Selection` properly after deleting composition r=m_kato

Comment 12

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/855263bb7dd2