[Disesfgewu]

Problem and behavior

Example drawing showed only a strip of its 16:10 canvas inside the test drawer and scrolled the rest: about 30% of it at first and at most 65% with the divider dragged all the way up (the table in #579). An Expand button, first on the drawing toolbar, now lays the board over the editor panel and shows the whole canvas at the largest 16:10 size the panel allows. The left sidebar, with the problem statement and the interview controls, stays visible and usable, and Jim's stage becomes the compact caption card a narrow window already has. Shrink or Escape returns to the editor with the code, the drawer height and the strokes unchanged.

At 1280x800 the canvas goes from 838x143 visible (of 838x524) to the whole 838x524.

Expanded, with "Hello" written on the board:

Shrunk back, after asking Jim what is on the board; he answers that it says "Hello":

Approach

The board keeps its one canvas and only its container moves, so the strokes, undo and the image Jim reads through read_board are the same before and after expanding. The button names its action (Expand drawing / Shrink drawing) and carries no aria-pressed, following the one-pattern toggle rule from #251. Escape shrinks the board unless it comes from a field or a dialog (role=dialog or a native <dialog>), from an input method composing, as a held repeat or with a modifier, or another handler has already taken it with preventDefault; the Escape that shrinks the board is marked the same way, so a later listener does not act on it too, and neither Escape nor the button acts during an ink stroke or while a text box is drawn, moved or scaled, so nothing is cut or moved by a size change. Focus stays where the key came from; when a click leaves focus in what the board covers, as Safari and Firefox on macOS do, expanding moves it to Shrink.

Nothing the board covers can be operated while it is expanded: the rest of the editor panel and the board's own summary are inert, and Cmd/Ctrl+Enter is taken but runs nothing, since its results would land in the covered drawer; the shortcut, now in workspace.js, asks through the test panel's covered(), which calls a new expanded() on what mountExampleBoard returns rather than reading the board's DOM. Shrinking clears inert only on the nodes expanding set it on, so a node something else holds inert stays so. The sidebar stays usable, and Shrink or Escape restores all of it; if something closes Example drawing while it is expanded, the board shrinks and the editor is freed as well. The pane sits at z-index: 6, under the overlays (10), so the setup check, the wait for the report and the report show over an expanded board, and over the editor panel's own layers, such as the transformed Test results chevron, which would otherwise show through it. While expanded the panel does not scroll, so in #579's 1250x630 window with the divider at its maximum, where the panel overflows by a few pixels, the board stays at the panel's top, and shrinking puts the panel back where the candidate had scrolled it. Expanding also scrolls the drawing to the canvas's top, and shrinking puts the docked strip back where the candidate had scrolled it, once the drawer has measured its docked height again, so a resize while expanded does not clamp the strip against its old height (the panel's scroll comes back in the same step): a text box near the bottom keeps its controls below the canvas, so the drawing can still scroll, and from a strip scrolled down to that box the top of the canvas was cut off by 113px at 1250x630. While expanded the drawer also leaves the docked drawing's height alone instead of measuring it from the box the board floats in, and measures it again on shrink.

Jim's stage takes the board the way it takes a narrow window: interview.js already makes it a compact card when the window or the editor panel is too narrow for the avatar, and an expanded board is now a third reason. The card keeps the Live CC captions, the turn ring and its status, the audio controls, Resume audio when the browser blocks playback, and a small self-view, over the board's bottom-right corner at z-index: 7, so the captions stay on screen and are still announced. The avatar and Hide avatar go, as in a narrow window (focus left on Hide avatar, as Safari and Firefox on macOS leave it after a click on Expand, moves to the stage, as when an automatic turn-off hides the button; the same now holds when a narrow window or panel makes the stage compact), and with no width left for its mount the avatar stops drawing until the board shrinks, as docs/avatar-contract.md describes for a narrow stage. Pressing Hide avatar before expanding changes nothing here, and shrinking gives a wide window its full stage back with its avatar state as it was. During the wait for the report its own rule still lifts the stage, now the card, over the dialog, and Escape from the card leaves the board alone, since the board behind the dialog is inert. The board stays expanded if Jim moves to the behavioral round, until the candidate shrinks it; after shrinking, Cmd/Ctrl+Enter runs again wherever the page allows a run. docs/avatar-contract.md now names all three reasons the stage is compact, the window, a narrow editor panel and an expanded Example drawing, where it hides the avatar and where the render loop stops.

The canvas keeps its full size; the card covers part of its bottom-right corner. Measured at the issue's sizes with a caption showing: 1.8% of the canvas at 1280x800, 1.3% at 1440x900 and 2.6% at 1920x1080, and 9.0% at 1250x630 with the divider at its maximum. With a self-view in the card (simulated at 4:3) these are 7.3%, 5.1%, 4.3% and 15.0%. A long caption grows the card to its usual cap, min(40vh, 20rem), and then it covers 12.5%, 8.8%, 6.0% and 20.8% without a self-view. The card passes pointer events through except on its captions and controls, as it does over the code when docked, so ink can still be drawn under its other parts, where it stays out of sight, though not out of Jim's image, until the board shrinks; a text box in that corner can have its Confirm and Cancel under the card, where Ctrl+Enter, Escape and Tab still reach them. I also tried keeping the full stage beside the board, with room kept on the right: that costs the canvas the stage's column for the full panel height, and at 1280x800 the canvas drops to about 666x416, about 37% less area. Where the stage sits is #512's decision.

The full-stage variant, not part of this PR:

Validation

• node --test tests/browser/example-board-ui.test.js: 25 pass in Chromium. The new tests check, at 1280x800, 1440x900 and 1920x1080, that the expanded board shows the whole canvas over the editor panel only and leaves the sidebar clickable; that strokes drawn before and while expanded stay on the canvas, in the image published for Jim and undoable; that the button or Escape shrinks it but not from a sidebar field, and that Escape leaves focus where it was, on the board's button, a tool or the sidebar; that Escape from an input method, a held repeat or a modifier chord, one another handler has taken and one from a native dialog leave it expanded, and that the Escape which shrinks it is marked as taken while a docked one is not; that an ink stroke and a text box being drawn, moved or scaled hold off Enter and Space on the button, docked and expanded, and Escape while expanded, each key checked alone, and that the button works again once the gesture ends; that nothing in the covered panel is reachable while expanded and exactly the same controls are reachable after shrinking, by the button and by Escape, that a node already inert stays inert after shrinking, round after round, and that a close while docked frees nothing; that a scripted click, which like Safari's leaves focus in the editor, moves it to Shrink; that at 1250x630 expanding with a text box at the canvas's bottom shows the canvas from its top; that shrinking puts the docked strip back where it was scrolled, down and across in a panel narrower than the canvas; that the real ending wait from interview.html covers the board and keeps its own Escape; and that closing Example drawing shrinks it and leaves nothing in the panel inert.
• tests/browser/interview-layout.test.js, on the interview page itself: the setup check, the ending wait and the report each cover an expanded board (this fails with the former z-index: 30), and the board covers the panel's Test results chevron (this fails without z-index: 6); the board stays within a pixel of the panel's top at 1250x630 with the divider at its maximum, under the wheel and when the panel was scrolled before expanding, and the panel's scroll comes back on shrink; with the divider at its maximum and the window then shortened while expanded, the docked height is left as it was until shrinking gives the docked drawing the height the drawer gives it at the new size (without the drawer's data-expanded observer it came back at 334px against 178px at 1280x600); after a resize from 1440x900 to 1280x700 the strip's scroll comes back whole, at 220px, where restoring it before the drawer measures again leaves it at 120px; at 1440x900 and 900x800 the stage is the compact card while expanded, its captions and Resume audio on top of the board, its volume slider keeping Escape for itself, the avatar's mount at zero width and Hide avatar gone, where at 1440x900 both are there before expanding, and at 1440x900 it is the full stage again after shrinking; over an expanded board the ending wait shows the card's captions on top and Escape from the card leaves the board expanded; expanding with focus on Hide avatar moves it to the stage; and the whiteboard page, which has no Example drawing, keeps the full stage in a wide window through resizes. tests/browser/run-shortcut.test.js checks that Cmd/Ctrl+Enter runs nothing while expanded and runs again after shrinking.
• tests/browser/run-shortcut.test.js: Cmd/Ctrl+Enter is taken and runs nothing while the board is expanded, and runs the tests again once it shrinks; this fails without the covered() check.
• Removing each added JavaScript and CSS line in turn fails at least one test, except five visual-only declarations (pane gap, padding and background, the surface's transparent background and the canvas paper color), which the screenshots cover; the canvas's min-width: 0, which matters only when the expanded canvas is narrower than 32rem, below the issue's sizes; and the textarea in Escape's field guard: the board's own label takes Escape first, the other textareas are covered while it is expanded, and a docked Escape changes nothing.
• ./scripts/test.sh on macOS: the browser lane ran 2880 tests, 2854 passed, none failed and 26 Java tests skipped without a JDK; ESLint and indent pass. task-authoring-tests, run-budget-tests, interactive-review-hook-tests and git-hooks fail for reasons outside this change, as on clean main on this machine: no rss_kb on macOS, the /private/var path alias, no timeout, shellcheck or ruff installed, and a timing ratio.
• Live interview on a local server: wrote "Hello" on the expanded board, shrank it, asked Jim what I had drawn, and he answered "Hello" (screenshots 1 and 2, taken before the stage became a card while expanded).
• Not checked: Firefox, Safari, touch and pen input. In a short window such as 1280x500 the Expand button can scroll out of view because of the editor panel's existing minimum height.

Close #579

[Alan52254]

The measurements in the issue and the three-viewport test make the problem and the fix easy to check, and keeping one canvas so strokes, undo and Jim's image do not change is the right call. jserv's threads already cover tab order, text-box gestures and the z-index; I checked those against the diff and agree, so I have not repeated them. My comments are about two places where the tests would still pass if the layout broke, and one focus behavior. The most useful change is to build the test shell from the real interview.html overlays, because that is what would have caught the z-index problem.

[princelu1009]

Keeping one canvas and only restyling its container is a clean way to keep strokes, undo and Jim's image identical. The existing threads cover tab order, text-box gestures, stacking and the test shell, so I have not repeated them. My comments are about one change I could not make any test fail without, and two places where the diff could be smaller.

No merge conflicts at the current head.

[jserv]

Rebase the current branch onto the upstream default branch and resolve any conflicts. Run /codetrial-review in AI agents (use $codetrial-review in Codex) and resolve all identified issues. Rework the series into minimal, logically coherent commits, squash closely related commits, and ensure all commit messages follow the project’s rules.