[lexical] Bug Fix: Ignore beforeinput and input events in captured decorators

[etrepum]

Description

Firefox 152 changed how it dispatches beforeinput events which caused lexical to process text input when it should be captured in the decorator's native input (this also applies to controls added via DOMSlot, which work very similarly).

onBeforeInput

• Adds the event context to the update for BEFORE_INPUT_COMMAND dispatch, but only dispatches when input is not captured

onInput

• Now only dispatches when input is not captured (it already had the event context)

isSelectionWithinEditor

• Only silences exceptions around the DOM calls, invalid code can fail now
• Reads $isSelectionCapturedInDecoratorInput with editor context (would fail silently before)

$isSelectionCapturedInDecoratorInput

• Renamed from isSelectionCapturedInDecoratorInput (it requires an active editor, wasn't named correctly before)
• Treats any activeElement contained in a LexicalNode containing an input, textarea, or non-LexicalEditor contenteditable as

$markSlotEditable

• Any contentEditable="true" (can be named slots or the children DOMSlot) now contains a __lexicalEditor property like the RootElement to let event handling know that their contents should be handled by lexical

Closes #8738

Test plan

New browser unit test to simulate this condition, no version of playwright has Firefox 152 yet so we can't do a meaningful e2e test

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
lexical	Ready	Preview	Jun 24, 2026 5:25am
lexical-playground	Ready	Preview	Jun 24, 2026 5:25am

[potatowagon]

Reviewed by Navi (Tater Thoughts Bobblehead) on behalf of @potatowagon.

LGTM ✅ — Bug fix: Ignore beforeinput and input events in captured decorators.

What this does: Extracts the "is this input from a captured decorator?" check out of $handleInput and into a shared shouldIgnoreInputFromCapturedSelection helper. This helper is now called in both onBeforeInput (early-return before dispatchCommand(BEFORE_INPUT_COMMAND, ...)) and onInput (wrapping the updateEditorSync call). Previously, only the input event was filtered at the command handler level — beforeinput was never filtered, meaning decorator inputs (e.g. <input> elements inside DecoratorNodes) would still trigger BEFORE_INPUT_COMMAND and potentially corrupt editor state.

What I checked:

1. Logic correctness: The helper checks two paths — (a) composed event target is directly inside a capturing decorator, and (b) the active element (via getActiveElementDeep for shadow DOM) is a capturing decorator. Both are existing guards, just factored out and applied earlier.
2. Behavioral change: Moving the guard from $handleInput (after updateEditorSync entry) to onInput (before updateEditorSync) means no editor update cycle is started at all for captured decorator inputs. This is strictly better — avoids unnecessary commit overhead.
3. beforeinput coverage: The new early-return in onBeforeInput fills a real gap. Without it, Firefox in particular fires beforeinput that bubbles to the contentEditable root even when focus is on an inner <input>. This could trigger BEFORE_INPUT_COMMAND handlers that assume a Lexical selection context.
4. Test quality: 108-line browser test simulates exactly the Firefox scenario — dispatches untrusted beforeinput/input from a focused decorator <input>, then document.execCommand. Verifies neither BEFORE_INPUT_COMMAND nor INPUT_COMMAND fire, and the native input still works (input.value === "a").
5. www compat: No removed/renamed exports. No API surface changes. The fix only suppresses spurious events — www consumers of BEFORE_INPUT_COMMAND/INPUT_COMMAND will simply stop receiving events they should never have received.
6. Edge cases: Shadow DOM path handled via getActiveElementDeep. Null checks on rootElement/activeElement present. rootElement.contains(activeElement) ensures only elements within this editor are checked.

CI: Core unit (22.x + 24.x), browser (all platforms), integrity, integration, e2e plain-text (linux + windows) — all GREEN. Remaining e2e (collab, mac, rich-text) still pending.

Ready to approve once remaining e2e completes.

[levensta]

If events from decorators are supposed to be ignored, why are key shortcuts propagates on to the editor?

Screen.Recording.2026-06-23.at.23.25.24.mov

[etrepum]

This ignores them when they are captured in a native input, textarea, or some other active element that isn't a lexical editor.

[etrepum]

This change affects beforeinput & input events and how selection is mapped, keyboard shortcuts are handled by keydown events which doesn't have this check