Expand description
BrowserPaneManager: embeds browsers as native OS child windows using CefBrowserHost::CreateBrowser. All creation runs on the CEF UI thread.
The Browser instance is owned by the host reducer’s browsers map (keyed
by label, accessed via AppState::get_browser etc). We only need the
block_id → label mapping, which also lives in the reducer’s panes map.
Lifecycle states are tracked explicitly via the reducer’s BrowserPaneLifecycle:
Created → Closing → Closed (removed from panes)
Every pane-facing op (focus/resize/navigate/…) short-circuits when the
entry is already in Closing. This drops late IPC that the frontend
fires after it has already asked for close but before CEF has destroyed
the Browser — stale IPC against a mid-destruction HWND is the shape of
the crash described in docs/specs/SPEC_BROWSER_PANE_LIFECYCLE.md §4c.
Phase H.1.d/e (PR #5): The legacy pane::lifecycle::PaneStateMachine
is gone; pane state lives only in HostState.browser_panes. All mutations go
through HostCommand::TryRegisterBrowserPaneLive / EnqueueBrowserPaneClose /
CompleteBrowserPaneClose / DrainBrowserPaneByLabel and read back via the reducer’s
atomic DispatchOutput fields.
Structs§
- AppState
Close 🔒Ops - Production implementation of
BrowserPaneCloseOpsbacked byAppState.browsersand Win32DestroyWindow. - Browser
Pane Manager
Traits§
- Browser
Pane Close Ops - Abstraction over the CEF-side operations
close()performs on the host process. Production implements this over&Arc<AppState>and Win32; tests implement it with a recording mock so the close-path state machine can be exercised without real CEF/HWNDs.