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

Project	Deployment	Preview	Comments	Updated (UTC)
lexical	Ready	Preview	Comment	Sep 29, 2025 6:25am
lexical-playground	Ready	Preview	Comment	Sep 29, 2025 6:25am

Might be a good opportunity to set up a test suite that runs in vitest browser mode now that we are not using jest?

My primary concern is that we don't know exactly when the ownerDocument will change, in the general case I think a node could be adopted by another document at any time. It would be good to see the sort of code that requires this sort of workaround, maybe it would be better to figure out how to set or reset the rootElement after it is in the correct Document and add some documentation about why that should happen and how to do it.

The counter situation should be fixable by using a Set<editor> instead of a number. Maybe also add some robustness to the event handler if it receives an event for a document that doesn't correspond to the current root ownerDocument (and either do the fix-up or log a warning about how to handle roots that change ownerDocument correctly).

Will give that a go.

Changed tack a little bit per your suggestion, and am now tracking which document the element was registered with, then decrementing the counter for that document. I stuck with WeakMap given that's what the initial implementation used, but can switch to Map if you're not worried about the potential memory leak if editors aren't cleaned up properly.

My primary concern is that we don't know exactly when the ownerDocument will change, in the general case I think a node could be adopted by another document at any time.

This is still a concern, however I couldn't see a good way to solve it in the general case. The closest I could find was MutationObserver, but in our case, the node was never actually attached to the original document's tree, so I don't think that'll help.

Which is to say, it'll still be up to the caller to track how they're moving elements around in documents. For us, we'll be able to do something like:

const [contentEditable, setContentEditable] = useState();
useEffect(() => {
    if (!contentEditable) {
        return;
    }
    // If editor is mounted in a portal in a different document,
    // re-register it so listeners are attached correctly.
    editor.setRootElement(null);
    editor.setRootElement(contentEditable);
}, [editor, contentEditable]);
...

<ContentEditable ref={setContentEditable} ... />

For posterity, I spent a bit of time trying to get browser mode going but couldn't get it over the line. Here's what I had:

      {
        define: {
          IS_REACT_ACT_ENVIRONMENT: true,
          __DEV__: true,
          LEXICAL_VERSION: JSON.stringify(
            `${process.env.npm_package_version}+git`,
          ),
        },
        extends: true,
        plugins: [
          tsconfigPaths({projects: ['./tsconfig.test.json']}),
          // lexicalTestMocks(),
        ],
        test: {
          browser: {
            provider: 'playwright',
            enabled: true,
            headless: true,
            instances: [{browser: 'chromium'}],
          },
          include: ['packages/**/__tests__/unit/**/*.test{.ts,.tsx,.js,.jsx}'],
          name: 'browser-unit',
          setupFiles: ['./vitest.setup.mts'],
          typecheck: {
            tsconfig: './tsconfig.test.json',
          },
        },
      },

lexicalTestMocks is commented out because it was erroring with "Cannot define a nested project for a chromium browser. The project name "browser-unit (chromium)" was already defined." otherwise. The above was still failing with "Caused by: ReferenceError: process is not defined ❯ packages/lexical/src/LexicalEditor.ts:1424:24", which is where I stopped looking into it.

An alternative to the WeakMap would be to store the owner document as a property on the editor.