Struct BrowserPaneManager 

pub struct BrowserPaneManager;

Implementations

impl BrowserPaneManager

pub fn new() -> Self

fn live_browser(&self, state: &Arc<AppState>, block_id: &str) -> Option<Browser>

Look up the Browser iff the pane is Live. Returns None when closing so all ops short-circuit uniformly.

pub fn pane_url(&self, state: &Arc<AppState>, block_id: &str) -> Option<String>

Return the current URL of the pane’s main frame, if the pane is Live. Used by the browser DOM API resolver (crate::browser_api::resolver) to match CEF /json targets against block ids without a first-class browserId field on the CEF side.

pub fn create( &self, state: &Arc<AppState>, block_id: &str, url: &str, rect: Rect, window_label: &str, ) -> Result<(), String>

pub fn navigate( &self, block_id: &str, url: &str, state: &Arc<AppState>, ) -> Result<(), String>

pub fn resize(&self, block_id: &str, rect: Rect, state: &Arc<AppState>)

pub fn close(&self, block_id: &str, state: &Arc<AppState>)

Close a pane by destroying its child HWND directly and dropping the Browser Arc.

We deliberately do not call host.close_browser(force). Empirically (host-log trace v0.33.251 and v0.33.252 in SPEC_BROWSER_PANE_LIFECYCLE.md §4), CEF Alloy treats the pane Browser and the main Browser as a single close unit when the pane’s outer HWND is a child of main’s top-level: close_browser(pane) fires do_close on main too. Previous attempts (force=0, force=1, a cascade-guard cancelling main’s do_close) either quit the whole app or orphaned the pane’s pixels while blocking the pane’s own teardown.

Instead:

1. Remove the Browser from state.browsers so subsequent lookups miss.
2. Win32 DestroyWindow on the pane’s outer HWND. The pane HWND is a WS_CHILD; WM_DESTROY cascades to descendants only, never to the parent. Main stays up.
3. Drop our Browser Arc. CEF still holds refs (browser_list etc.); on_before_close may eventually fire on the now-destroyed Browser, which is why drain_closed_label is idempotent.

Trade-off: because we bypass close_browser, Chromium’s beforeunload handler doesn’t run. Acceptable for a browser pane (no form data the user expects to persist across close). If beforeunload becomes important, revisit.

fn close_with(label: &str, ops: &dyn BrowserPaneCloseOps)

The testable side-effect body of close(). Given a pane’s label, remove its Browser handle and destroy its HWND. The state-machine transition (Live→Closing) and the entry removal (CompleteBrowserPaneClose) happen in close() via reducer dispatch — close_with is purely the FFI side-effects that follow.

pub fn drain_closed_label(&self, state: &Arc<AppState>, label: &str)

Called from CEF’s on_before_close if/when it fires for a pane browser. The explicit close() path usually clears the entry first, so this is a no-op in that case — but on_before_close may still fire async as Chromium’s refcount hits zero, and DrainBrowserPaneByLabel is idempotent so the callback is safe.

pub fn go_back(&self, block_id: &str, state: &Arc<AppState>)

pub fn go_forward(&self, block_id: &str, state: &Arc<AppState>)

pub fn reload(&self, block_id: &str, state: &Arc<AppState>)

pub fn defocus_all(&self, state: &Arc<AppState>)

Tell every live pane browser it has lost focus, at the Chromium level. Panes in Closing are skipped — their HWND may be mid-destruction and set_focus(0) against it can hit an invalid render widget.

pub fn set_pane_overlay_clip( &self, state: &Arc<AppState>, window_label: &str, overlay_rects: &[(i32, i32, i32, i32)], )

Apply a clip region to every live pane HWND that subtracts the given overlay rects (in main-window client coordinates). The pane renders normally outside the overlay region; inside it, the HWND is transparent so the DOM overlay painted at the same screen position shows through.

This is the Win32 “airspace” workaround — native HWNDs always paint above DOM regardless of CSS z-index, and SetWindowRgn is the one mechanism that lets DOM bleed through a specific region of a child HWND. Empty overlay_rects restores full pane visibility (same as calling clear_pane_overlay_clip).

No-op on non-Windows: other platforms don’t use native child HWNDs for panes, so there’s no airspace to work around.

window_label scopes the clip to panes whose top-level ancestor matches the requesting window. Without it, a modal opened in window B would clip panes in window A (see Codex P1 on PR #544). Empty string matches today’s legacy callers that don’t know their window label — falls through to the no-filter behaviour for back-compat until every caller is updated.

pub fn focus(&self, block_id: &str, state: &Arc<AppState>)

Give keyboard focus to the pane’s child HWND so keystrokes reach the embedded page. Called by the frontend’s ViewModel.giveFocus() when the pane becomes the active layout node — without this, focus falls back to the main window’s invisible “dummy-focus” input and keystrokes vanish.

No-ops if the pane is Closing: a SetFocus against a HWND that CEF is concurrently tearing down is the exact race documented in SPEC_BROWSER_PANE_LIFECYCLE.md §5 race #2.