ianstormtaylor/slate · error · Error

Unable to find a host window element for this editor

Error message

Unable to find a host window element for this editor

What it means

Thrown by DOMEditor.getWindow when the editor has no registered host window, i.e. the EDITOR_TO_WINDOW WeakMap entry was never set by attaching the editor to DOM withEditable/withDOM. It means DOM-specific APIs are being used on an editor that was never bound to the DOM layer.

Source

Thrown at packages/slate-dom/src/plugin/dom-editor.ts:471

        const domRange = DOMEditor.toDOMRange(editor, editor.selection)
        domSelection?.removeAllRanges()
        domSelection?.addRange(domRange)
      }
      // Create a new selection in the top of the document if missing
      if (!editor.selection) {
        Transforms.select(editor, Editor.start(editor, []))
      }
      // IS_FOCUSED should be set before calling el.focus() to ensure that
      // FocusedContext is updated to the correct value
      IS_FOCUSED.set(editor, true)
      el.focus({ preventScroll: true })
    }
  },

  getWindow: editor => {
    const window = EDITOR_TO_WINDOW.get(editor)
    if (!window) {
      throw new Error('Unable to find a host window element for this editor')
    }
    return window
  },

  hasDOMNode: (editor, target, options = {}) => {
    const { editable = false } = options
    const editorEl = DOMEditor.toDOMNode(editor, editor)
    let targetEl

    // COMPAT: In Firefox, reading `target.nodeType` will throw an error if
    // target is originating from an internal "restricted" element (e.g. a
    // stepper arrow on a number input). (2018/05/04)
    // https://github.com/ianstormtaylor/slate/issues/1819
    try {
      targetEl = (
        isDOMElement(target) ? target : target.parentElement
      ) as HTMLElement
    } catch (err) {

View on GitHub (pinned to 72a37c701e)

Solutions

1. Create the editor with DOMEditor.withDOM (usually via withReact from slate-react)
2. Only call DOM helpers after the <Editable> component has mounted
3. In SSR/tests, guard window-dependent calls behind a mounted check
4. For pure data manipulation, use slate core APIs (Node, Transforms) instead of DOMEditor

Example fix

// before
const editor = createEditor()
const win = DOMEditor.getWindow(editor)
// after
const editor = withDOM(withReact(createEditor()))
// after <Editable> mounted:
const win = DOMEditor.getWindow(editor)

const editor = withDOM(withReact(createEditor()))
// and only after <Editable> mounts:
if (EDITOR_TO_WINDOW.get(editor)) { /* safe to use DOM APIs */ }

const isDOMAttached = (editor: Editor): boolean =>
  EDITOR_TO_WINDOW.has(editor) // or track a mounted flag in your own state

try { DOMEditor.getWindow(editor) } catch (e) { if (/host window/.test(e.message)) skip DOM-specific logic; else throw e }

When it happens

Trigger: Calling editor.getWindow(), hasSelectableTarget, or other DOM helpers on an editor created with createEditor() instead of withDOM(withReact(createEditor())), or calling them before the editable component mounted.

Common situations: Using slate-dom utilities in Node/SSR or in unit tests without mounting <Editable>; creating a standalone editor for data manipulation but accidentally calling DOM APIs; import order causing withDOM to be skipped.

Related errors

• Cannot resolve a Slate range from a DOM event: ${event}
• Unable to find the path for Slate node: ${Scrubber.stringify
• Could not set focus, editor seems stuck with pending operati
• Cannot resolve a DOM node from Slate node: ${Scrubber.string
• Cannot resolve a DOM point from Slate point: ${Scrubber.stri

AI-assisted analysis of ianstormtaylor/slate@72a37c701e (2026-08-27). Data as JSON: /api/errors/f36ab11b09b962b9. Report an issue: GitHub.