[lexical] Bug Fix: Handle MutationObserver/input event re-ordering when using contentEditable inside of an iframe

[etrepum]

Description

Sometimes when an iframe is used as the contentEditable then the MutationObserver can fire after the input event, even if the mutation actually did happen. This causes problems that were undiagnosed prior to the addition of $validatePoint in __DEV__ (part of #6759) because the Lexical selection would refer to DOM coordinates that were not yet valid in the Lexical document, because the DOM was mutated before getting the selection. When the mutation observer happens first this doesn't occur because either the mutation is applied and/or the selection code is skipped due to getIsProcessingMutations() (see $internalCreateRangeSelection). This is related to the optimization(?) in #794 that avoids explicitly flushing root mutations on input.

This PR:

• Adds a vanilla-js-iframe example as a testbed for checking that iframe events are handled correctly, with a dev:monorepo script so you can run it with the monorepo like the playground rather than with the npm installed lexical for easier development/debugging (maybe we add this to other examples?)
• Fixes up some incorrect $function naming
• Uses updateEditorSync instead of updateEditor in the places that I visited along the way, for in-order execution
• Adds a currently internal event option to UpdateOptions so that the reason for the update can be captured in a way that's accessible by the code in $internalCreateRangeSelection that checks to see if it's from a mutation or from some specific set of events before deciding whether to use the DOM selection or not. We don't want to use the DOM selection before input because it might refer to DOM coordinates that do not exist in the lexical document yet.
• Consistently use getWindow for editor._window in the core package (just a general clean-up while investigating)

Closes #7028

Test plan

I'm not exactly sure how to reasonably add tests for this

Before

Error when typing into the end of a TextNode in an iframe on Chrome or Firefox

After

No more errors

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 12, 2025 8:45pm
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 12, 2025 8:45pm

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	31.48 KB (0%)
lexical - esm	31.2 KB (0%)
@lexical/rich-text - cjs	40.54 KB (0%)
@lexical/rich-text - esm	33.21 KB (0%)
@lexical/plain-text - cjs	39.06 KB (0%)
@lexical/plain-text - esm	30.37 KB (0%)
@lexical/react - cjs	42.43 KB (0%)
@lexical/react - esm	34.48 KB (0%)

[zurfyx]

That's a tricky one, thanks for looking into this! 😮

[zurfyx]

Do we foresee any performance impact of sync update events? I presume that this makes it possible for multiple reconciliations to happen almost simultaneously

[etrepum]

No performance impact, the behavior only differs for nested updates in which case it’s inlined like dispatchCommand instead of deferred to after the current updateFn returns. It just runs code in the order you expect it to happen, doesn’t otherwise change semantics of reconciliation which still happens on the tick after the updating started (note that no tests had to change here).