[Firefox] When typing in another input field, the cursor is automatically moved to the Lexxy editor instead.

[shved270189]

Steps to reproduce:

1. Open a page with the Lexxy editor and another input field in Firefox. My Firefox version is 152.0.1 (aarch64).
2. Add images to the Lexxy editor.
3. Type something between the images.
4. Move the cursor to another input field and start typing.

Current behavior:

The cursor is moved back to the Lexxy editor.

Expected behavior:

The user should be able to type in the other input field without interruption, and the cursor should remain there.

Screen.Recording.2026-06-22.at.11.24.12.mov

[lyubomir-bozhinov]

I'd like to look into this one.

One note for triage: despite the title, the reproduction steps here are about attachments/images rather than mentions. That may still be related — images (ActionTextAttachmentNode) and mentions (CustomActionTextAttachmentNode) both extend Lexical's DecoratorNode, so this could share a root with #1148/#1149.

src/editor/selection.js#containEditorFocus currently installs a capture-phase keydown workaround for a Chrome bug where focus escapes the editor around decorator fake-cursors; I want to check whether Gecko needs separate handling there, and why focus returns to the editor once it has legitimately moved to another field.

Will confirm in Firefox before proposing a fix.

[lyubomir-bozhinov]

I picked this one up, but I have not managed to reproduce it — so rather than sit on it, here is exactly what I tried, in case it helps narrow things down.

Against main (ec8d46e), in Playwright's Firefox, with the editor and a second input on the same page, I ran four variants:

1. two images set via editor.value, click the other field, type
2. same, but typing between the images first, then moving to the other field
3. two real uploads (mocked Active Storage), left to settle, then typing in the other field
4. an upload still in flight — move to the other field, type, and let the upload complete there

In all four, on Firefox and Chromium, focus stayed in the other field and the text landed there. The editor never pulled the caret back.

So I am missing a condition from your setup. Anything you can share would help:

• Does it reproduce on a fresh Rails app with the dummy editor, or only inside a specific app? (Asking because a couple of things filed here have turned out to be host-app behaviour rather than Lexxy itself.)
• Were the images still uploading when you moved to the other field, or fully settled?
• Is the other field a plain <input>, or something inside a modal/frame?
• Anything in the console when the cursor jumps back?
• Does it still happen on current main?

One thing that stands out: you are on Firefox 152.0.1, and Playwright currently ships Firefox 146. If this is a newer Gecko regression, that alone would explain why my runs come up clean — so it would be useful to know whether it reproduces for you in an older Firefox too.

For what it's worth, while looking at this I did find and fix two genuine Firefox bugs in the same area, both mention-related rather than image-related: #1149 (#1204) and #1148 (#1205).

[shved270189]

@lyubomir-bozhinov,

Steps to reproduce:

1. Open https://lexxy.dev/ in Firefox.

2. The demo page doesn't have a second input, so add this above Lexxy:

<input type="text">

3. Upload 2 images and arrange them vertically (one above the other).
4. Start typing between the images.
5. Switch focus to the text input from step 2.
6. Start typing in the input created in step 2.

Actual result:

The cursor jumps back to the Lexxy editor, away from the input created in step 2.

Expected result:

The user continues typing in the input from step 2 without the cursor being redirected.

For more details, see the video:
https://drive.google.com/file/d/1eWlhiPNq--8yYFi8y5TNJbsIoayn2nau/view?usp=sharing

[lyubomir-bozhinov]

@shved270189 thank you — those steps were exactly what I needed, especially the two images stacked vertically with the caret between them. That's the state that triggers it.

The reason my earlier attempts came up empty: it only reproduces on Firefox 152. On 146 and 151 the same steps behave correctly, so the version detail was the missing piece. Once I ran it on 152 it reproduced immediately — typing in the outside input landed the first character, then the caret jumped back into the editor, matching your video.

Root cause: with a caret between two stacked block images, Lexxy keeps an invisible placeholder paragraph before and after the images. It refreshes those on every selection change so the caret spacer can follow the cursor — but it wasn't checking whether the editor was actually focused. Firefox 152 started firing selectionchange for an outside input's caret (146/151 don't), which drove that refresh and pulled focus back into the editor.

Fix is up in #1210: the refresh now bails out when the editor isn't focused, so a selection change elsewhere on the page leaves your focus alone. Verified against real Firefox 152, with a regression test that fails without the fix.

[lyubomir-bozhinov]

Correction to my earlier comment: the real fix for this is #1209, not my #1210, which I have now closed.

@jeremy had already fixed it in cd72f36 on July 20 — a day before I got my reproduction working — and I simply missed the overlap. His fix addresses the same root cause but at a better level: Firefox 152+ keeps window.getSelection() anchored inside the editor after focus moves to another field and then fires selectionchange for every keystroke typed there, so Lexical reconciles that stale selection and drags focus back. #1209 tags the update with skip-dom-selection while an outside text field holds focus, which covers every path into that reconcile. Mine only guarded one of them.

@shved270189 — your steps were what made this reproducible, so thank you for taking the time to write them up with the video. The version detail turned out to be the crux: it only misbehaves on Firefox 152 and later, which is why it resisted reproduction for so long. I confirmed the fix against your exact scenario (two stacked images, caret between them, typing in an input above the editor) on Firefox 153:

• before Keep focus in other form fields when reconciling a stale selection #1209: focus jumps back into the editor after the first keystroke
• on current main with Keep focus in other form fields when reconciling a stale selection #1209: focus stays in the input and every keystroke lands

The fix is released in v0.9.27 (current is v0.9.28), so upgrading should sort it out on your end. Worth a check against your app when you get a chance — and if you still see it after upgrading, that would be worth reporting, since it would mean a second path into the same reconcile.