[robertjamesprior]

Summary

Keeps a headful window covering the display during the first 10 seconds after each Chromium start, while the image and window manager settle. It watches X11 _NET_WM_STATE and re-maximizes a non-fullscreen window when coverage drops.

Compatibility boundary

The guard is intentionally bounded to startup and restart stabilization. Deliberate client resizes after the 10-second window are left alone. Within the window, the three-correction budget prevents an unstable client from being fought indefinitely.

Why

The existing promotion restores maximized state once per Chromium start. It does not cover a demotion caused by a saved geometry, a window-manager restore, CDP, or the Playwright executor that runs after promotion. The guard catches those startup demotions without changing the reduced-work-area behavior caused by a desktop panel.

How it watches

xprop -spy watches _NET_WM_STATE instead of polling. A state change is confirmed over CDP, and only a non-maximized, non-fullscreen window is corrected. The guard stops after the stabilization window, when deliberate client geometry should take precedence.

Testing

• go test -race ./cmd/api/api ./lib/x11
• go vet ./...
• go test -v -race $(go list ./... | rg -v /e2e$)
• New unit coverage covers the correction budget, maximized and fullscreen exemptions, CDP correction, and direct plus Playwright demotions.
• The live probe observed a demotion and correction on the current release image. The guard itself still requires an image release for deployed validation.

---

Note

Medium Risk
Headful-only behavior that issues CDP Browser.setWindowBounds in response to X11 events; bounded by time and correction budget, with fullscreen/kiosk left alone.

Overview
Adds a headful-only startup guard (StartWindowReconcile) that runs alongside existing one-shot window promotion. For the first 10 seconds after each Chromium start, it watches the active window’s X11 _NET_WM_STATE via xprop -spy; when coverage drops (not fully maximized), it confirms state over CDP and re-applies maximized bounds, up to 3 corrections, then stops so deliberate client resizing can win.

New server/lib/x11 helpers resolve the active window and stream WM state changes. E2E now expects demotions via direct CDP and Playwright executor to be re-maximized with desktop-filling geometry, not left in normal state.

^{Reviewed by Cursor Bugbot for commit c91bc1a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chruffins]

One decision needed before merging

This change keeps the browser window full-screen even when a customer's code makes it smaller on purpose. In testing, a customer's requested smaller window was reverted within about a second. The first three times this happens in each browser session, the change puts the window back, and after that it leaves the window alone.

Should a customer's deliberate resize be respected?

• Option A: Keep the window full-screen every time. Document this as a visible change for customers.
• Option B: Let a customer's deliberate resize stick, and only correct resizes they didn't ask for.

Everything else I tested works as described.

[robertjamesprior]

good catch. option b is the intended compatibility contract: deliberate client resizes should stick. i narrowed the guard to the first 10 seconds after each chromium start, where the startup and restart failure occurs; after that window it stops watching, so later client resizes are left alone. the reduced-work-area panel case remains separate.

[chruffins]

I'm trying to look for a more specific root cause so that I can suggest a fix that's less hacky. I need a bit to work on this