[lexical] Bug Fix: Do not move anchor when inserting composition start char#8121
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Looks like this is failing e2e tests |
|
Thank you! Before I finalize the fix, I have a question regarding a behavior I observed in the E2E test(Can type Hiragana via IME part way through a mention). In this test case, when the Hiragana character 'す' is entered, a COMPOSITION_SUFFIX (an invisible character) is inserted. I noticed that when I try to move the cursor from 'す' back to the 'e' in "Luke", I have to press the arrow key twice to pass the invisible character. Is this behavior intentional or unintended side effect? If it is a side effect, I am going to update the E2E test accordingly. |
|
It’s only intentional if that’s how IME normally works in native text fields. |
|
Lexical inserts COMPOSITION_SUFFIX to prevent input errors during composition. However, it is currently only removed from the end of the text, leaving intermediate ones behind. These suffixes cause unexpected behavior. I will update the related e2e tests to ensure all instances are properly cleaned up. |
0c95ff2 to
456b363
Compare
|
The test is passed. But there is incorrectly behavior in the firefox when input the composition text. So, I am working on fix it. |
…ion-starting-with-formatted-text
etrepum
left a comment
There was a problem hiding this comment.
When you call editor.update from inside of another update to the same editor it will run the code out of order, which is very confusing and makes it difficult to debug. I think this should be unnecessary, or should be refactored to make this deferral explicit in some way because this behavior will change at some point in the future (at least generate warnings).
I created #8133 which is this PR plus a commit that makes all of these synchronous, can you check to see if that works as expected for you?
|
At least with Chrome on macOS it looks like the cursor is in the wrong place when doing composition with this PR (compared to the current playground and Apple's TextEdit input behavior) - this PR is on the left Screen.Recording.2026-02-11.at.10.26.43.mov |
|
Thanks for the catch! I'm already on it. The bug manifests as a simple position error on macOS, but on Windows, it causes false input position when formatting is applied during composition. I'll include the fix for this in my next push with your previous review. |
|
You should be able to cherry-pick this commit which may include changes that I didn't mention in review comments 8d35f04 |
|
@etrepum I resolved all issue in this PR and the tests are all passes! complete.mov |
etrepum
left a comment
There was a problem hiding this comment.
Code looks good, thank you! The lexical team doesn't currently have any active contributors with much IME expertise so this is very helpful
Description
Current Behavior
Lexical inserts a
COMPOSITION_START_CHARto ensure the browser correctly handles IME composition. However, when this character is inserted, the selection anchor moves forward and first composition stroke is in a selected state. Windows Chrome manages to continue the composition session, But macOS Chrome drops the first stroke and composing is failed.Changes in This PR
COMPOSITION_START_CHARis inserted at the beginning of a composition session.COMPOSITION_START_CHARin the text and reconcile the anchor and focus positions appropriately.Closes #8119
Test plan
Before
before.mov
After
after.mov