This browser does not support setCustomValidity(validationMe

Error message

This browser does not support setCustomValidity(validationMessage) for trix-editor elements.

What it means

setCustomValidity(validationMessage) on trix-editor is a stub that only logs this warning in browsers without form-associated custom element support, so custom validity messages can never be registered on the element. Subsequent checkValidity/reportValidity will not reflect any custom state. Non-fatal console warning.

Source

Thrown at src/trix/elements/trix_editor_element.js:366

  }

  setFormValue(value) {
  }

  checkValidity() {
    console.warn("This browser does not support checkValidity() for trix-editor elements.")

    return true
  }

  reportValidity() {
    console.warn("This browser does not support reportValidity() for trix-editor elements.")

    return true
  }

  setCustomValidity(validationMessage) {
    console.warn("This browser does not support setCustomValidity(validationMessage) for trix-editor elements.")
  }

  #resetBubbled = (event) => {
    if (event.defaultPrevented) return
    if (event.target !== this.element.form) return
    this.element.reset()
  }

  #clickBubbled = (event) => {
    if (event.defaultPrevented) return
    if (this.element.contains(event.target)) return

    const label = findClosestElementFromNode(event.target, { matchingSelector: "label" })
    if (!label) return

    if (!Array.from(this.labels).includes(label)) return

    this.element.focus()

View on GitHub (pinned to 4700401311)

Solutions

Store custom error state yourself (e.g., a data attribute or wrapper component state) and render it, rather than relying on setCustomValidity.
Only call setCustomValidity after confirming form-associated support; otherwise apply a custom error-rendering path.
Accept the warning as benign and rely on your own validation UI.
Upgrade the runtime to a browser where constraint validation works for custom elements.

Example fix

// before
editor.setCustomValidity(serverError);
// after
if (supportsFormAssociatedElements()) {
  editor.setCustomValidity(serverError);
} else {
  editor.dataset.customValidity = serverError;
  showCustomError(editor, serverError);
}

Defensive patterns

Strategy: fallback

Validate before calling

if (!('ElementInternals' in window)) {
  // setCustomValidity is a no-op on trix-editor; store errors in app state
}

Type guard

function canSetCustomValidity(el) {
  return el instanceof HTMLElement && 'ElementInternals' in window && typeof el.setCustomValidity === 'function';
}

Try / catch

try {
  editor.setCustomValidity(serverError);
} catch (e) {
  editor.dataset.customValidity = serverError;
}
if (!('ElementInternals' in window)) renderCustomError(editor, serverError);

Prevention

Keep server-side validation errors in application state, not on the DOM element
Render custom error messages in a dedicated UI region for trix-editor
Feature-detect ElementInternals before calling setCustomValidity
Re-render custom errors on editor change so state stays consistent

When it happens

Trigger: Calling 'trixEditor.setCustomValidity("...")' (e.g., after server-side validation errors) in an unsupported browser, executing the stub at trix_editor_element.js:365-367.

Common situations: Apps piping backend validation errors into controls via setCustomValidity; form libraries managing custom error state; older Safari/Firefox deployments.

Related errors

AI-assisted analysis of basecamp/trix@4700401311 (2026-09-02). Data as JSON: /api/errors/b4b2ec0b954e3913. Report an issue: GitHub.