Stop the editor stealing focus from the sidebar

[ssavutu]

Editing an image caption and then typing in the author or section search box put the first letter in the search box and the rest back in the article.

Three separate paths lead there. All of them end the same way: Trix re-renders and restores its own selection, and the browser's focus goes with it.

1. We were mutating Trix's DOM on every keystroke

The alignment effect wrote CSS classes onto the <figure> elements inside the contenteditable on every trix-change. Trix's MutationObserver treats that as a foreign mutation: it re-parses the document, re-renders it, and restores the selection. Editing a caption fires trix-change per keystroke, so each one queued a re-parse; click into the sidebar while one is in flight and the pending restore lands a keystroke later.

Alignment now comes from CSS attribute selectors on the data-trix-attributes JSON Trix writes itself, so nothing of ours touches the contenteditable. This also fixes the editor stealing focus on page load for articles with aligned images.

2. A stale selection left behind when focus leaves

Trix decides an attachment is no longer being edited by watching for a selectionchange whose range isn't the attachment's own. While an image sat in that state the check stayed armed after the author had clicked away — and Firefox raises selectionchange on the document when you type in a plain <input> (Chrome raises it on the input). So the first letter typed into the sidebar fired the teardown, whose re-render took the focus back. This is the path that reproduces the reported symptom letter-for-letter.

Fixed by clearing the stale DOM selection on focusout, which leaves Trix reading no range instead of a stale one. Calling stopEditingAttachment() there does not work — it runs the same teardown and steals focus just as thoroughly.

focusout rather than trix-blur: while a caption is open the focus is on the caption field, so the editor element never blurs.

3. The first click into a caption did nothing

Trix opens the caption field on mousedown and focuses it a tick later. In between, the selection settles outside the attachment's range, Trix stops editing the attachment, and the deferred focus() lands on an element no longer in the document. The caption took a second click to enter, and the first click had quietly dropped focus out of the editor.

Fixed by re-opening the caption once after the click settles. Trix ignores a request to edit the attachment it is already editing, so it is a no-op when nothing broke; a click elsewhere in the window cancels the pending restore.

Testing

Driven in a real browser against the article editor with a stubbed API — Chromium and Firefox, against both plain and legacy WordPress-aligned article bodies:

• single-click caption entry, and the typed text committing to the caption
• typing in the sidebar search after a caption edit (the reported bug)
• clicking from a caption straight into the body, and into the sidebar
• image selection and the attachment toolbar
• body typing before and after a trip out to the sidebar
• the toolbar tracking a selection made after returning from the sidebar

Green in all four combinations. vitest 11/11, tsc and eslint clean.

Not changed

The blue outline on a selected image (.attachment--selected) never shows, because Trix's re-render drops the class we add — the same "we mutate Trix's DOM" pattern. Pre-existing and identical before and after this change, and the image still reads as selected via Trix's own toolbar and caption highlight. Left for a follow-up.

🤖 Generated with Claude Code