* fix(web): keys typed into an editor frozen by force_refresh recovery stay in the editor (BUG-3786)
BUG-3697 made the editor read-only through a force_refresh recovery. A
read-only Tiptap editor is contenteditable=false with no tabindex, so the
browser drops its focus to <body>, outside the item pane. The page and
layout shortcut guards then no longer see a text field: the BUG-3697 spec's
"Typed during recovery." opened the quick-add dialog on its `c`, and the
rest of the text went into that dialog. For a user, an arrow or Enter would
also move the pane to another item.
While frozen, the editor keeps a tabindex of -1, so it stays focusable
inside the pane and behind the pane's guards, and a typed character stops
propagating at it: exactly what characterKey() returns, which is what
every single-key shortcut reads. Escape, Tab, arrows, Enter, space and
chords still reach their window owners (DockedSheet, the PaneHost focus
trap, scroll restore), as they do from an editable editor; codex r2 and
r3 found those owners when the hold was wider. ProseMirror's listener is
on the same node and still sees every key.
The spec is live again (the test.fixme that #2137 parked it under is
removed), and now asserts that the frozen editor holds focus and that no
quick-add dialog opened. Counterfactuals: without the tabindex the focus
premise fails; with the tabindex but without the keydown hold, the
quick-add assertion fails.
Main's CI failure (the pane ending on another item) did not reproduce
locally, alone or with the shard's neighbouring specs. The quick-add leak
reproduced on every local run, including passing ones.
Claude-Session: https://claude.ai/code/session_01Rj4CMyK2EqxerMihbGs3Kr
* test(e2e): the BUG-3697 spec focuses the frozen editor instead of force-clicking it (BUG-3786)
#2138's first CI run went red on E2E desktop 1/2 at the focus premise,
before any typing. The trace (run 38472264516) shows the pane closing
during `click({ force: true })`. The click point (1098, 619) is
(686, 387) on the 0.625-scaled screencast frame, where an
"E2E Admin created 2 items →" activity toast sat, stacked above the
recovery's own toast. A forced click skips the hit-target check, so it
clicked the toast's link and the pane left. Main's original failure
(the pane ending on another spec's CONVE-868) is the same thing: a
toast's item link.
editor.focus() reaches the editor without a coordinate. On main's
ItemDetail the frozen editor has no tabindex, so focus() leaves it
unfocused and the premise still goes red there.
Claude-Session: https://claude.ai/code/session_01Rj4CMyK2EqxerMihbGs3Kr
xarmian
5ea7fde86b