oficina / docs Public

Two commits: a click anywhere on the page now places the caret, and the browser's focus ring no longer traces a blue box around the editable area. Reported by Paul from a screenshot of the editor.

What was actually wrong

Neither symptom was a bug in anything this app had written. Both were the default behaviour of an editable <div> that nobody had told to behave like a page.

The blue box was the browser's own focus ring. Every browser draws one around a focused contenteditable, and on a white sheet of paper it read as a text box sitting on the document rather than as the document itself.

The dead clicks were a geometry problem. [docs-editor] is the same element as [docs-text], so it was only ever as tall as its own prose. The page's 1in margin and the empty space below the last paragraph belonged to [docs-page] — not to anything editable — so a click there landed on nothing at all and did nothing. That reads as a broken document rather than a short one.

The fix, in two halves, because the two regions are not the same problem

The empty space below the last line can be given to ProseMirror, so it is: [docs-page] becomes a flex column and the editor a grown child (flex: 1 0 auto), which stretches the editable node to the full height of the page's text area. Basis auto with shrink 0 so a document longer than one page still lays out at its own height and pushes the page taller rather than being squeezed back into 11in.

The margins can never be given to it — they are [docs-page]'s own padding, and an editable node has no way to reach outside itself. So placeCaretFromPage (fixtures/editor-entry.js) handles those on mousedown: it clamps the click's coordinates into the editable node's rectangle and asks posAtCoords, which is what turns "beside the text" into "at the nearest end of the nearest line". It reads currentView at event time rather than a captured view, so a resync — which destroys the whole EditorView and builds another — does not leave it dispatching into a dead one.

outline: none is scoped to [docs-editor] alone. The header's sign-out button and the save-status chrome keep rastrillo's own focus styling untouched.

The review round, and the one finding that mattered

Reviewed as a single diff by Fable per AGENTS.md. Verdict: safe to merge, no blocking or high findings. It confirmed the things most likely to be wrong and were not — the listener survives resync without leaking (registered once on an element that outlives every view), the selection-only transaction produces no Y update so the save queue never sees it and no row is spent against core.go's maxRetainedUpdates, the committed bundle hash is genuinely its own content, and drag-select inside the editor, right-click and middle-click paste all still work because the handler returns early for in-editor targets and only ever claims button 0.

The finding worth acting on was an accessibility one, and it is worth writing down because the argument for removing a focus ring is exactly the kind that is true in the case you are looking at and false in the case you are not.

Dropping the ring rests on the caret being a stronger focus indicator than a box. That holds for a click, which puts the caret where you just looked. It does not hold for the keyboard: Tab in from the sign-out button on a document scrolled away from wherever the selection was last left, and ProseMirror restores that selection without scrolling to it — its focus() does not scroll, deliberately — so focus arrives with no visible indicator anywhere in the viewport. The ring, whose edges would have been on screen, used to cover that case for free. AGENTS.md's rule is WCAG 2.2 AA with no exemptions, so this is not a trade to make quietly.

An empty transaction now carries a scrollIntoView on focus. The subtlety is that it must fire only for focus that did not arrive by pointer: a focus event is dispatched before ProseMirror has set the selection the click asked for, so scrolling on every focus scrolls to the stale selection instead — click into the third page of a document and the view yanks back to the first, which is a worse bug than the one being closed. :focus-visible cannot make that distinction, because a contenteditable takes keyboard input and so matches it whatever the modality was. Hence a flag that a pointer press sets and the next macrotask clears.

Two smaller findings, both fixed: TextSelection.near is not an API — TextSelection defines no static near of its own in prosemirror-state 1.4.4, so it silently resolved to the inherited Selection.near while reading like a promise that the result is a TextSelection, which near does not make. And one comment reasoned from something untrue (an empty document does not lack a line to be near; it holds an empty paragraph that resolves fine) — the fallback was right, its stated why was not.

Left undone, on purpose

Shift-click in the margin collapses a selection rather than extending it, and a drag that starts in the margin places a caret but does not grow a selection as the pointer moves. Both are refinements to margin behaviour that did not work at all before this branch, neither regresses what was reported, and inventing selection semantics from coordinates is its own piece of work rather than a loose end of this one.

How it was verified

Not by the test suite, which cannot see any of this. Driven in Chromium against scripts/run-dev.sh, signed in for real through a magic link, on the longest seeded document (5,528 characters):

left-margin click, level with the 3rd block -> caret at offset 0 of that block
click below the last line                   -> caret at end of the last block
bottom-margin click                         -> caret at end of the last block
click at the top, selection left at the end -> scrollY stays 0 (no yank)
Tab in, selection off-screen                -> scrolled to it, caret on screen
focused editor                              -> outline-style: none
typing                                      -> lands at the caret

go test ./internal/... ./cmd/... and node --test fixtures/*.test.mjs pass. Full CI gate green.

Deploying to https://docs.bds.oncarlos.com straight after the merge — the edge channel is what that host follows.