This browser does not support reportValidity() for trix-edit

Error message

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

What it means

reportValidity() on trix-editor is a fallback that warns and returns true in browsers lacking form-associated custom element support. No native error bubble/UI is shown and the element always reports as valid. Non-fatal console warning.

Source

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

    console.warn("This browser does not support the willValidate property for trix-editor elements.")

    return false
  }

  formDisabledCallback(value) {
  }

  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

View on GitHub (pinned to 4700401311)

Solutions

Implement your own error display for trix-editor (custom message + styling) instead of reportValidity().
Call reportValidity only after feature detection; otherwise run a custom validation routine for the editor.
Accept the benign warning; the true return value safely lets submission proceed.
Update browsers in your support matrix to versions with form-associated custom elements.

Example fix

// before
if (!editor.reportValidity()) return;
// after
const ok = editor.reportValidity() && customValidateTrix(editor);
if (!ok) { showCustomError(editor); return; }

Defensive patterns

Strategy: fallback

Validate before calling

const ok = isValidControl(editor);
if (!ok) showCustomError(editor); // do not depend on reportValidity UI

Type guard

function reportValidityOrCustom(el) {
  const native = el.tagName !== 'TRIX-EDITOR' && typeof el.reportValidity === 'function';
  return native ? el.reportValidity() : customValidate(el);
}

Try / catch

try {
  if (!editor.reportValidity()) return;
} catch (e) {
  /* ignore */
} finally {
  if (!customValidate(editor)) showCustomError(editor);
}

Prevention

Build custom error UI for trix-editor instead of native reportValidity bubbles
Call reportValidity only after feature detection
Combine native and custom validation results before allowing submit
Verify submit-time UX in browsers without form-association support

When it happens

Trigger: Calling 'trixEditor.reportValidity()' during submit-time validation or after user interaction, in an unsupported browser, executing the stub at trix_editor_element.js:359-363.

Common situations: Submit handlers calling form.reportValidity() (which delegates to each control), custom 'show errors' buttons, older Safari/Firefox environments.

Related errors

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