Respect contenteditable elements when checking for editability

[iansan5653]

In focus-zone we check to see if focus is on an input element before applying focus change commands, since character keys should always be typable in inputs and arrow keys should typically control selection.

However, this doesn't currently consider contenteditable inputs, which are any HTML element that can act like it's an input.

This PR adds a new isEditableElement util that determines whether an element is editable. This helper is duplicated from our internal codebase; once this ships I can remove the duplicated code from over there.

It also adds some specific handling to reuse the textarea multiline logic on contenteditable elements.

This fixes https://github.com/github/core-ux/issues/669 (internal issue).

[changeset-bot]

🦋 Changeset detected

Latest commit: 4905192

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@primer/behaviors	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Pull Request Overview

This PR updates the focus-zone component to respect contenteditable elements when determining if an element is editable, treating them similarly to traditional input elements for keyboard navigation handling.

• Introduces a new isEditableElement utility function that detects editable elements including contenteditable elements
• Refactors focus handling logic to use the new utility instead of hardcoded input/textarea checks
• Adds specific multiline input handling for contenteditable elements similar to textarea behavior

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/utils/is-editable-element.ts	New utility function to determine if an element is editable, including contenteditable support
src/focus-zone.ts	Updated focus handling logic to use the new utility and treat contenteditable elements as multiline inputs

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The readonly check is duplicated between ariaReadOnly property and aria-readonly attribute. The ariaReadOnly property should already reflect the aria-readonly attribute value, making the second check redundant.

Suggested change

target.getAttribute('aria-readonly') === 'true' ||

[Copilot]

The removal of the single-character key handling for select elements is problematic. Select elements should ignore typeable characters (keyLength === 1) as they change the selection, but this logic was removed when switching to isEditable. This will cause focus zone navigation to trigger inappropriately when typing in select elements.

Suggested change

	if (activeElement instanceof HTMLSelectElement) {
	if (activeElement instanceof HTMLSelectElement) {
	// Ignore single-character (typeable) keys, as they change the selection
	if (keyLength === 1) {
	return true
	}

[Copilot]

Copilot detected a code snippet with 2 occurrences. See search results for more details.

Matched Code Snippet

,
  'checkbox',
  'color',
  'file',
  'hidden',
  'image',
  'radio',
  'range',
  'reset',
  'submit',
])

/**
 * Returns true if `element` is editable - that is, if it can be focused and typed in like an input or textarea.
 */
export function isEditableElement(target: EventTarget | null): boolean {
  if (!(target instanceof HTMLElement)) return false

  const name = target.nodeName.toLowerCase()
  const type = target.getAttribute('type')?.toLowerCase() ?? 'text'

  const isReadonly =
    target.ariaReadOnly === 'true' ||
    target.getAttribute('aria-readonly') === 'true' ||
    target.getAttribute('readonly') !== null

  return (
    (name === 'select' ||
      name === 'textarea' ||
      (name === 'input' && !nonEditableInputTypes.has(type)) ||
      target