Present into the window, not over the screen

[HamptonMakes]

Presenting a deck over Zoom didn't work, and native fullscreen was the reason.

On macOS a fullscreen window moves onto its own Space, and apps sitting in a fullscreen Space drop out of screen-share pickers entirely — so requestFullscreen was quietly removing the browser from Zoom's window list at the exact moment you wanted to share it. Taking the whole screen also buries the call controls the presenter is talking through.

What changed

start() no longer requests fullscreen. The screen was never the mechanism anyway: the top-layer popover in _promoteDeck is what fills the space, and the deck canvas is already sized in viewport units. So the show now fills the browser window, which is exactly what you pick in a share dialog.

f mid-show toggles native fullscreen, for the times there's a projector and no call.

Fullscreen became a mode within the show rather than the show itself — losing it drops back to the window instead of ending the presentation. Two consequences:

• Escape gained a rung. It already peeled one layer at a time (popovers, then the pen); now the screen is a layer too, and only a bare Escape ends the show. Full screen is the one layer the presenter took deliberately, so Escape should undo that, not everything.
• _peeling is gone. It existed solely to forgive the uncancelable fullscreen exit that Escape used to trigger. There's nothing left to forgive.

No CSS rules changed — min(100vw, 100vh * 16/9) means the canvas just grows into the screen when f lands. Only the section comment and the Present button's key legend needed updating.

Why not something cleverer

I looked for a web API that would hand Zoom a dedicated surface. There isn't one:

• navigator.presentation — Safari has never implemented it (no support on any version, macOS or iOS), and even in Chrome it hands a URL to a second-screen receiver (Chromecast, a presentation display). There's no macOS window for Zoom to pick up.
• getDisplayMedia — an input, not an output. A page can capture the screen; it cannot publish one. A MediaStream's only sinks are <video>, RTCPeerConnection, and Web Audio. Feeding Zoom would need a native virtual camera (a CoreMedia I/O extension, the OBS Virtual Camera approach).
• Element Capture / Region Capture — Chromium-only, and they only apply to the page doing the capturing. Zoom is the capturer here.
• Document Picture-in-Picture — Chrome 130, Firefox 151, Safari never. Also moving the deck into another document would disconnect the Stimulus controllers and the live-update target, breaking the "a collaborator's edit lands mid-show" behavior.

So "make the window shareable" is the whole solution space, and it's a deletion.

Testing

New spec in spec/system/deck_ux_spec.rb covers: no fullscreenElement on start; the deck sized to the window's largest 16:9 fit and genuinely in the top layer; f entering fullscreen; Escape returning to windowed with the show still running on slide 1; a second Escape ending it.

Deck suite plus the plans request specs: 119 examples, 0 failures.

For the reviewer

• Verified in headless Chrome, not Safari. The mechanism is the Popover API plus viewport units — both solid in Safari 17+ — and this change removes the browser-specific API call rather than adding one. Still worth one manual Zoom-share confirmation.
• Windowed present means the browser window is a black 16:9 canvas with letterbox bars filling the remainder. Correct for sharing, but a visibly different feel from before.
• f is keyboard-only; there's deliberately no mid-show chrome. It's advertised in the Present button's title alongside p and d, which is the only place the show's keys are listed.

🤖 Generated with Claude Code

One thing a reviewer should question

The new example opens the plan at its readable address (visit "/#{plan.url_path}") while its neighbours use plan_path(plan). That inconsistency is deliberate but unresolved.

On CI — both DB jobs, deterministically — that one example got a Rails routing error for /_/plans/<uuid>, the path plan_path generates. Diagnostics showed the plan record intact (slug="readout-deck", handle="presenter", visibility="published"), both Rails.application.routes and CoPlan::Engine.routes failing to recognize that path, and the engine mounted once with its member routes (publish, hide, archive) present in the same set. Re-requesting failed identically.

What I could not explain: the two examples above it fetch that exact path successfully in the same process, and every example below passes. Moving it from sixth to third position in the file changed nothing. engine/config/routes.rb has no conditionals, the engine is a path gem, no spec redraws routes, and locally the path resolves under both lazy and eager loading.

Visiting the readable address is defensible on its own — it's the canonical URL, PlansController#show 301s the id form onto it, and it's what a presenter actually opens. But it's a step around the anomaly, not an explanation. The anomaly predates this branch and is filed for separate investigation.