CEF Views: new windows briefly appear at hidden sentinel before WRR snaps them on-screen

[AgentA-asaf]

Symptom

When opening a new top-level window (status-bar "open new window", tab tear-off, etc.), the window briefly appears at the Win32 hidden sentinel position (-31970, -31970) before WRR's CorrectiveWindowMove saga snaps it onto the primary monitor at the requested offset.

End-state position is correct. The bug is purely cosmetic — a visible flash.

Reproducibility

The flash is fast enough that it's not always noticeable in normal use. Confirmed visible on slower display refresh rates / debug-mode builds.

Root cause hypothesis

agentmux-cef/src/commands/window.rs::open_window_with_kind computes a position via get_offset_position() (30px right + 30px down from active window) and passes it to post_create_window. The CreateWindowTask constructs the AgentMuxWindowDelegate with the position, then in on_window_created (CEF callback after the OS window exists) calls window.set_bounds(...).

CEF Views appears to use its own default placement (the hidden sentinel) during the OS window's CreateWindowEx call, before on_window_created fires. The post-create set_bounds then re-positions the window — but the user sees the brief intermediate state.

Suggested fix path

Override WindowDelegate::initial_bounds(&self, window) -> Rect so CEF Views queries the requested bounds BEFORE the OS window is created and bakes them into CreateWindowEx. The cef-rs binding exposes this hook (verified — ImplWindowDelegate::initial_bounds is callable in the wrap_window_delegate! macro).

Tried but reverted (2026-04-29): a naive implementation returning Rect { 0, 0, 0, 0 } for the no-explicit-bounds case (main window) broke rendering entirely — CEF Views took the zero-area rect literally and produced a black 0×0 window. A real fix needs:

1. A correct sentinel for "use Views' default placement" (or unconditionally returning a valid rect by computing the centered-70%-of-monitor fallback BEFORE the window exists, which means we can't query window.bounds() for the monitor-detection step the current get_monitor_centered_70pct does).
2. Verify behaviour across DPI scales and multi-monitor setups.

Why deferred

• Cosmetic only — WRR already lands the window in the correct final position.
• Phase F (host reducer) will re-touch this code path and might restructure the bounds-passing API; a fix here may be redundant by then.
• Higher-impact work (Phase D durability/resync, Phase E srv reducer) is on the critical path; this fix can wait.

When to pick this up

• Anytime someone has bandwidth + a careful CEF Views debug session.
• Or as part of Phase F if the host-reducer migration of commands/window.rs is touching this code anyway.

Related

• docs/retro/next-steps-2026-04-29.md §1.1 — original write-up
• docs/retro/multi-reducer-status-2026-04-29.md §4.2 — captured as parked Phase F item
• WRR design: docs/retro/wrr-design-2026-04-28.md
• Code: agentmux-cef/src/app.rs (AgentMuxWindowDelegate::on_window_created), agentmux-cef/src/commands/window.rs::open_window_with_kind, agentmux-cef/src/ui_tasks.rs::CreateWindowTask

🤖 Filed via Claude Code