This browser does not support the [disabled] attribute for t

Error message

This browser does not support the [disabled] attribute for trix-editor elements.

What it means

Trix's trix-editor custom element implements form-participation APIs (disabled, required, validity, etc.) as no-op fallbacks for browsers that do not support form-associated custom elements (HTMLElement 'formassociated'). Accessing or setting 'disabled' on a trix-editor in a browser without that support hits the fallback getter/setter, which logs this console warning and returns false. It is a non-fatal capability warning, not a thrown exception.

Source

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

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

    return null
  }

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

    return null
  }

  set name(value) {
    console.warn("This browser does not support the .name property for trix-editor elements.")
  }

  get disabled() {
    console.warn("This browser does not support the [disabled] attribute for trix-editor elements.")

    return false
  }

  set disabled(value) {
    console.warn("This browser does not support the [disabled] attribute for trix-editor elements.")
  }

  get required() {
    console.warn("This browser does not support the [required] attribute for trix-editor elements.")

    return false
  }

  set required(value) {
    console.warn("This browser does not support the [required] attribute for trix-editor elements.")
  }

View on GitHub (pinned to 4700401311)

Solutions

Upgrade/require a browser with form-associated custom elements support (Chrome 77+, Firefox 93+, Safari 16.4+) so the native behavior is used.
Treat the warning as expected noise: the accessors safely return false and never throw; filter the warning in dev tooling if it clutters logs.
Stop relying on the DOM [disabled] attribute for trix-editor; gate editor interaction yourself (e.g., toggle 'contenteditable'/'readonly' or hide the editor) when form-association is unsupported.
Wrap editor disabled-state logic in a capability check: CSS.supports or presence of HTMLElement accessibility to form association, falling back to manual enable/disable code.

Example fix

// before
editor.disabled = isSaving;
// after
if ('form' in HTMLElement.prototype && supportsFormAssociated()) {
  editor.disabled = isSaving;
} else {
  editor.setAttribute('contenteditable', isSaving ? 'false' : 'true');
}

Defensive patterns

Strategy: fallback

Validate before calling

const supportsFormAssociated = () =>
  typeof HTMLElement !== 'undefined' &&
  Object.prototype.hasOwnProperty.call(HTMLElement.prototype, 'disabled') === false &&
  ('ElementInternals' in window);
// guard: only set editor.disabled when ElementInternals form-association is available
if (!('ElementInternals' in window)) { /* use manual disable path */ }

Type guard

function canUseNativeFormDisabled(el) {
  return el instanceof HTMLElement && 'ElementInternals' in window && 'form' in el;
}

Try / catch

try {
  editor.disabled = isSaving;
} catch (e) {
  console.debug('form-associated unsupported, using manual disable');
  editor.contentEditable = isSaving ? 'false' : 'true';
}

Prevention

Feature-detect 'ElementInternals' in window before relying on native form APIs on trix-editor
Implement a manual enable/disable path (contenteditable + CSS class) as the universal fallback
Pin browser support requirements in docs/CI (Chrome 77+, Firefox 93+, Safari 16.4+)
Filter known benign console warnings in dev tooling so real issues stand out

When it happens

Trigger: Reading 'editor.disabled' or assigning 'editor.disabled = true' (or calling setAttribute('disabled', ...)) on a trix-editor element in a browser lacking form-associated custom element support, which causes the stub get/set disabled accessors at trix_editor_element.js:310-318 to run.

Common situations: Apps using Trix inside older Safari/Firefox versions (pre form-associated custom elements), feature detection gaps in form code that toggles editor disabled state, and tests running in browsers or environments without ElementInternals form support.

Related errors

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