oficina / docs Public

The menu bar had the same defect; the fix is now one shared module

Re-measuring the tab-reveal after the previous commit took the mutation
count from 23 to 5. The 18 removed were the toolbar's and are confirmed
gone. The 5 that remained were all "disabled: \"\" -> \"\" [REDUNDANT]",
all in fixtures/menu.mjs's sync:

    el.disabled = false
    el.disabled = !(view && command && command(view.state, null, view))

Both unconditional, on the same per-update path — menu.sync runs from
the toolbar's own plugin through onSync, so it fires on every
ProseMirror state update too. Setting a reflected boolean property to
the value it already holds still sets the content attribute, so it
still records a mutation and still invalidates style, for exactly the
reason the toolbar's setAttribute writes counted.

Worth saying plainly why it was there: menu.mjs was written AFTER the
toolbar, by a different session, and reproduced the defect from
scratch because nothing stopped it. A local pair of helpers in
toolbar.mjs would have let the next surface do it again. So setAttr and
setProp move to fixtures/dom-writes.mjs, which both bars import; there
is one copy of the comparison and one place the reasoning is written
down.

menu.mjs's two roving-tabindex writes go through setProp as well. They
are not on the update path and were not part of the flash, but leaving
them direct would have meant either a structural rule that exempts them
or a module with two different disciplines. Through the helper, arrowing
along the bar also stops rewriting the five titles whose tabindex was
already right.

The guard extends the same way rather than gaining a second file.
fixtures/toolbar.test.mjs now mounts BOTH bars the way editor-entry.js
does -- one plugin, the menu on its onSync, two roots because
[docs-toolbar] and [docs-menubar] both hold data-docs-command elements
-- so the property is held once across the whole chrome: after a state
update that changes nothing, zero writes. The structural rule covers
toolbar.mjs and menu.mjs, and is now simply "no direct DOM write in
either file". Two named files with a comment saying why: plenty of
modules here write to the DOM and should, but these two run on every
state update, from one plugin, which is what makes a redundant write
cost a frame.

Watched failing first, with menu.mjs reverted and toolbar.mjs fixed. The
no-op update logged exactly four writes, every one from === to, all of
them the menu's -- and none the toolbar's, which is the previous
commit holding:

    + { from: false, id: 'menu-strong',           name: 'disabled', to: false },
    + { from: true,  id: 'menu-undo',             name: 'disabled', to: true  },
    + { from: true,  id: 'menu-clear_formatting', name: 'disabled', to: true  },
    + { from: false, id: 'menu-print',            name: 'disabled', to: false }
    - []

and the structural test: "menu.mjs should get its writers from
dom-writes.mjs". Three mutations confirm the guards still bite: an
unconditional setAttribute added to menu.mjs's sync fails both the
behavioural and the structural test (the latter naming menu.mjs:311);
deleting a write that matters fails the counterweight test; and removing
setProp's own comparison in dom-writes.mjs fails the no-op test for both
bars at once.

menu.test.mjs keeps its own tests and gains a note saying what it cannot
see: it records the state an element ends up in, not the calls made to
get there, which is precisely why this defect lived under a green gate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>