Module browser_panes

Module browser_panes 

Source
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§

AppStateCloseOps 🔒
Production implementation of BrowserPaneCloseOps backed by AppState.browsers and Win32 DestroyWindow.
BrowserPaneManager

Traits§

BrowserPaneCloseOps
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.