[lexical][lexical-playground] Bug Fix: Add workarounds for buggy browser behavior around macOS text replacements by nmggithub · Pull Request #8417 · facebook/lexical

nmggithub · 2026-04-28T20:09:30Z

Description

This adds workaround behavior where typing a character to accept a macOS text replacement used to leave the caret before that character instead of after. It also adds workaround behavior where pressing Backspace (and performing Select All, apparently) would accept a pending macOS text replacement instead of deleting a character.

Closes #8413
Closes #8416

Test plan

There are tests added for the caret placement bug. The Backspace / Select All acceptance bug relies on native behavior that can't easily be synthesized, so there are no tests around that.

Before

Screen.Recording.2026-04-28.at.14.11.05.mov

Screen.Recording.2026-04-28.at.16.02.05.mov

After

Screen.Recording.2026-04-28.at.14.11.32.mov

Screen.Recording.2026-04-28.at.16.02.35.mov

…s in text replacements

…macOS text replacements

vercel · 2026-04-28T20:09:35Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lexical	Ready	Preview, Comment	May 1, 2026 4:35am
lexical-playground	Ready	Preview, Comment	May 1, 2026 4:35am

nmggithub · 2026-04-28T23:23:11Z

This might not actually be possible due to Chrome's bad heuristics. Still looking into it myself. EDIT: I think I figured it out now. It's a bit wonky but it does seem to work.

etrepum

I think we should try and smooth out all of the wonky text replacement behavior we can find in one pass, the behavior in chrome with this one is still a bit wonky. For example pressing return or space should accept the replacement then do the behavior of that key. Right now it just accepts the replacement and effectively prevents default (haven't done a thorough audit of that section of the events code to step through what it's doing, just QA). The best justification to do it all at once is to make sure that we add the minimum amount of implicit state machine to make it work rather than add a little bit for each workaround.

Safari seems to have the right behavior before this patch, can also be tested in chrome in any textarea.

etrepum · 2026-04-30T01:30:39Z

+  handledSelectionCommandTimeoutId = setTimeout(() => {
+    isInsertTextAfterHandledSelectionCommand = false;
+    handledSelectionCommandTimeoutId = null;
+  }, 0);


Looks like this is effectively the same as the above function, should save a few bytes to just call it

Suggested change

handledSelectionCommandTimeoutId = setTimeout(() => {

isInsertTextAfterHandledSelectionCommand = false;

handledSelectionCommandTimeoutId = null;

}, 0);

handledSelectionCommandTimeoutId = setTimeout(clearHandledSelectionCommandInsertText, 0);

Should be resolved by 2e29782.

etrepum · 2026-04-30T01:38:45Z

    } else if (isSelectAll(event)) {
      event.preventDefault();
-      dispatchCommand(editor, SELECT_ALL_COMMAND, event);
+      if (dispatchCommand(editor, SELECT_ALL_COMMAND, event)) {
+        markHandledSelectionCommandInsertText();
+      }


As far as I can tell this can be lifted up after isRedo and not repeated

Should be resolved by 2e29782.

nmggithub · 2026-04-30T01:58:21Z

@etrepum yeah, I'm not particularly happy with fix.

This patch of Chromium I submitted for Electron fixes it for Chrome: electron/electron#50432

To note, Chrome is the only browser between it, Firefox, and Safari, that has this bug.

#8414 is a different story. Firefox and Chrome exhibit that bug, but Safari doesn't.

Both bugs closely related, and there's spec questions to be had at how all three browsers implement InputEvents around macOS text replacements, but we have to work around those for both bugs here.

nmggithub · 2026-04-30T02:03:57Z

I think we should try and smooth out all of the wonky text replacement behavior we can find in one pass,

I find

Backspace accepts text replacement, and
caret ends up before the acceptance boundary,

to be two separate bugs (which is why I filed them separately). Bug 1 only exists in Chrome and is arguably because it has the worst implementation of InputEvents here (I could go into detail, but I'll save space here). Bug 2 exists in Chrome and Firefox because they both fire the Space, Return, Etc. event before the event that replaces the text. Safari fires the event that replaces the text first (hence how I wrote the test for #8414).

Again, we can't really change any of this, only work around it.

etrepum · 2026-04-30T03:09:45Z

I agree that conceptually these are different things because there are different keystrokes involved and have slightly different browser compatibility matrices. However, as far as reviewing goes it would be much easier and more efficient for me if I had one PR to review that worked around all of the known bad behavior with macOS text replacements. This PR for example is shipping without any sort of test infrastructure (playwright doesn't really make it feasible to write real tests for IMEs anyway) and requires manual QA in all of the browsers, so it would be way better if I only had to go through that process for one PR.

nmggithub · 2026-04-30T03:19:27Z

I agree that conceptually these are different things because there are different keystrokes involved and have slightly different browser compatibility matrices. However, as far as reviewing goes it would be much easier and more efficient for me if I had one PR to review that worked around all of the known bad behavior with macOS text replacements. This PR for example is shipping without any sort of test infrastructure (playwright doesn't really make it feasible to write real tests for IMEs anyway) and requires manual QA in all of the browsers, so it would be way better if I only had to go through that process for one PR.

Understandable, I can combine everything into this PR if you prefer, since we're having the convo here already.

etrepum · 2026-04-30T03:20:13Z

What I would like to see working (with the selection on the rightmost character except in the arrow key cases):

"omw<space>" results in "On My Way! "
"omw<backspace>" results in "om" (dismisses the text replacement and removes w)
"omw!" results in "On My Way!!" (most punctuation and symbols should accept and continue according to platform behavior elsewhere)
"omw<enter>" results in "On My Way!\n" (newline, in the default lexical case this would be a new paragraph)
"omw<arrowkey>" results in "omw" (dismisses the text replacement) and results in the default navigation for that key
"omw<esc>" results in "omw" (dismisses the text replacement)

Ideally this would just be one PR where I can carefully read through the code and all of the required context and run through all of the scenarios in each browser to verify expected behavior. With multiple PRs I have to repeat all of this.

In the current playground all of these work as expected in Safari, but the behavior is mixed in the other browsers

etrepum · 2026-04-30T03:20:45Z

Rolling it up into this PR works for me

…ext-replacements-accepted-by-backspace

nmggithub · 2026-04-30T05:17:12Z

A long bit of context for these bugs.

The bugs

The two bugs:

Backspace (and Select All, apparently) accepts a pending text replacement, and
caret ends up before the acceptance boundary after accepting a pending text replacement,

The `InputEvent`s

Safari (No Bugs)

Safari has, arguably, the most sensible behavior around these replacements. It exhibits neither of these bugs.

Typing omw<space> in Safari results in the last two InputEvents being:

{ inputType: "insertReplacementText", dataTransfer: { ... "On my way!" (equivalently) ... }), and
{ inputType: "insertText", data: " " } .

This gets two things right:

it uses insertReplacementText for the event that replaces the text (matching Input Events Level 2), and
it fires the Space event after the replacement event (which plays nicely with Lexical's event handling, leaving the caret in the correct spot).

Firefox (Bug 2)

Firefox flips the order, but at least gets insertReplacementText right:

{ inputType: "insertText", data: " " } , and
{ inputType: "insertReplacementText", dataTransfer: { ... "On my way!" (equivalently) ... }).

Chrome (Bug 1, Bug 2)

Chrome doesn't even use insertReplacementText for this:

{ inputType: "insertText", data: " " } , and
{ inputType: "insertText", data: "On my way!" }.

Chrome also is the only one that exhibits Bug 1.
From what I can tell, its due to some internal logic error. I've squashed Bug 1 in Electron by adding a Electron-local Chromium patch, but it's also possible that logic I patched was/is in plumbing that wouldn't even be hit if Chrome chose to use insertReplacementText for this instead (but I can't confirm that yet).

Regardless, Chrome's choice to not use insertReplacementText is apparently deliberate, with them only using it for their own first-party replacements. There is an open issue trying to get them to use insertReplacementText for maOS text replacements, though.

Proper Long-Term Solutions

Getting all browsers to adopt Safari's event ordering would likely finally squash Bug 2 and remove the need for our workaround.
Getting Chromium to use the insertReplacementText plumbing for macOS text replacements may squash Bug 1 and remove the need for our workaround, but it might entail a drift in deliberate policy by the Chromium team to not use insertReplacementText for third-party replacements (despite how arguably out-of-spec that is).

etrepum

This is much improved! I've found two edge cases that we should consider handling before this is merged:

Chrome - if you complete the text replacement with the same character that the replacement ends with, the selection ends up before the last character you typed.

Screen.Recording.2026-04-30.at.07.48.07.mov

Firefox - punctuation doesn't accept the text replacement

Screen.Recording.2026-04-30.at.07.48.57.mov

nmggithub · 2026-04-30T15:10:51Z

Firefox - punctuation doesn't accept the text replacement

This appears to be the current behavior before my patches in both contenteditable and regular textarea and input elements in Firefox. I don't know if we want to deliberately stray from that. I would liken this to the fact that Tab only accepts the text replacement in Chrome. It seems to be a consistent browser difference.

I will investigate the Chrome bug, though.

nmggithub · 2026-04-30T15:17:00Z

The lingering Chrome bug has been squashed! I left the Firefox bug as-is because it appears to be consistent across all kinds of inputs in that browser.

etrepum

QA looks great, agreed that it's fine to leave the Firefox behavior as-is. Will merge after taking a closer look at the code when I have the time.

nmggithub added 5 commits April 28, 2026 14:07

[lexical][lexical-playground] Bug Fix: Move caret past trailing space…

8225cc4

…s in text replacements

fix: make workaround work with any acceptance character

fd70cc1

Merge branch 'main' into fix-macos-text-replacements-on-chrome

63d0397

style: make prettier happy

4d570c9

[lexical][lexical-playground] Bug Fix: Stop Backspace from accepting …

311775c

…macOS text replacements

meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Apr 28, 2026

vercel Bot deployed to Preview – lexical-playground April 28, 2026 20:10 View deployment

vercel Bot deployed to Preview – lexical April 28, 2026 20:10 View deployment

etrepum added the extended-tests Run extended e2e tests on a PR label Apr 28, 2026

nmggithub added 3 commits April 28, 2026 16:52

fix: make workaround work in plain-text mode

9a1ae88

fix: add support for enter and tab acceptance

2557d7b

tests: add text-replacement test via Enter key

767c168

fix: use a stateful flag for heuristics

ab008f3

vercel Bot deployed to Preview – lexical-playground April 28, 2026 23:42 View deployment

vercel Bot deployed to Preview – lexical April 28, 2026 23:42 View deployment

nmggithub marked this pull request as ready for review April 28, 2026 23:50

nmggithub requested review from acywatson, etrepum, fantactuka, ivailop7, potatowagon, takuyakanbr and zurfyx as code owners April 28, 2026 23:50

etrepum reviewed Apr 30, 2026

View reviewed changes

nmggithub requested a review from etrepum April 30, 2026 02:05

nmggithub added 2 commits April 30, 2026 00:36

fix: address pr comments

2e29782

Merge branch 'fix-macos-text-replacements-on-chrome' into fix-macos-t…

2414494

…ext-replacements-accepted-by-backspace

nmggithub mentioned this pull request Apr 30, 2026

[lexical][lexical-playground] Bug Fix: Move caret past trailing characters in accepted macOS text replacements #8414

Closed

vercel Bot deployed to Preview – lexical April 30, 2026 04:47 View deployment

vercel Bot deployed to Preview – lexical-playground April 30, 2026 04:47 View deployment

nmggithub changed the title ~~[lexical][lexical-playground] Bug Fix: Stop Backspace from accepting macOS text replacements~~ [lexical][lexical-playground] Bug Fix: Add workarounds for buggy browser behavior around macOS text replacements Apr 30, 2026

etrepum reviewed Apr 30, 2026

View reviewed changes

fix: remove unnecessarily broad precondition for workaround

af73a83

nmggithub requested a review from etrepum April 30, 2026 15:17

vercel Bot deployed to Preview – lexical-playground April 30, 2026 15:17 View deployment

vercel Bot deployed to Preview – lexical April 30, 2026 15:17 View deployment

etrepum approved these changes Apr 30, 2026

View reviewed changes

Use $isBlockElementNode and clean up selection code a bit

eb8fdc0

vercel Bot deployed to Preview – lexical-playground May 1, 2026 04:35 View deployment

vercel Bot deployed to Preview – lexical May 1, 2026 04:35 View deployment

etrepum added this pull request to the merge queue May 1, 2026

Merged via the queue into facebook:main with commit f50bfbb May 1, 2026
38 checks passed

etrepum mentioned this pull request May 28, 2026

v0.45.0 #8580

Merged

Conversation

nmggithub commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Test plan

Before

After

Uh oh!

vercel Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nmggithub commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etrepum left a comment

Choose a reason for hiding this comment

Uh oh!

etrepum Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

nmggithub Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

etrepum Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

nmggithub Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

nmggithub commented Apr 30, 2026

Uh oh!

nmggithub commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etrepum commented Apr 30, 2026

Uh oh!

nmggithub commented Apr 30, 2026

Uh oh!

etrepum commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etrepum commented Apr 30, 2026

Uh oh!

nmggithub commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The bugs

The InputEvents

Safari (No Bugs)

Firefox (Bug 2)

Chrome (Bug 1, Bug 2)

Proper Long-Term Solutions

Uh oh!

etrepum left a comment

Choose a reason for hiding this comment

Uh oh!

nmggithub commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nmggithub commented Apr 30, 2026

Uh oh!

etrepum left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nmggithub commented Apr 28, 2026 •

edited

Loading

vercel Bot commented Apr 28, 2026 •

edited

Loading

nmggithub commented Apr 28, 2026 •

edited

Loading

nmggithub commented Apr 30, 2026 •

edited

Loading

etrepum commented Apr 30, 2026 •

edited

Loading

nmggithub commented Apr 30, 2026 •

edited

Loading

The `InputEvent`s

nmggithub commented Apr 30, 2026 •

edited

Loading