Multi-window: runtime window creation, and the singleton assumptions in the way

[glennmichael123]

Direction issue rather than a near-term ask. Today a craft app is exactly one window:

• No create/open action in bridge_window.zig:55-111; window.craft.window is implicitly "the" window, no handle anywhere.
• api.zig:199/254 can create windows from zig, but nothing routes that to JS or the CLI.
• Every bridge is a process-global singleton (macos.zig:4074 setupBridgeHandlers), and outbound JS resolves one global webview — every reply and event in the process is evaluated into a single page regardless of origin.
• The single NSWindowDelegate instance is process-global and re-attached to each new window (macos_window_events.zig:59-63).
• window.open() is separately dead (window.open() and target=_blank are silently dropped — route them to the system browser #64).

The eventual want (stacksjs/harness: "pop this session out into its own window") needs: craft.window.create({url,...}) → handle, window-handle addressing on the window namespace, per-webview reply routing, and per-window event scoping. Sequencing: request-id correlation (#66) is a hard prerequisite — "which call asked" must be solved before "which window asked" — and #63's app delegate is where multi-window lifecycle naturally lives. Filing now so the singleton pattern stops spreading into new bridges in the meantime.

🤖 Generated with Claude Code

[glennmichael123]

Round 2 (#62, #63, #64, #65, #66) is done, and four of those touch this issue directly. Notes for whoever picks it up, since the sequencing here changed.

The hard prerequisite is met

#66 landed request-id correlation. Every message the page sends now carries an i, and the dispatcher records it in a stack (src/request_context.zig) that bridge_error.zig reads back when it formats a reply — no handler was touched, and no handler can forget to forward it.

That matters for this issue beyond just being unblocked: the shape it introduced is the shape "which window asked" wants. Adding a w alongside i means one more field on the envelope, one more push/pop frame, and the reply formatter reads both. The 267 reply sites stay untouched a second time. Threading window handles through signatures would be the same 39-file mistake.

Also note the stack was needed, not preferred: runModal spins a nested run loop that keeps dispatching, so a scalar was already wrong for one window. Multi-window does not make that worse — it is already handled.

Two singletons were pre-emptively un-singletoned

The issue asks that the pattern stop spreading into new bridges. In round 2 it did not, in the two places it would have:

• src/webview_recovery.zig keys crash-retry budgets per webview in an 8-entry table, not one global counter. A window in a crash loop cannot spend the budget of a window that is fine — which is precisely the bug that would land the day a second window exists.
• macos.zig's content_slots (what to reload after a renderer crash) is keyed the same way, for the same reason.

Both are deliberately tables of eight rather than scalars. Neither needs unpicking.

#63's delegate is already multi-window shaped

applicationShouldHandleReopen: iterates [NSApp windows] and orders every craft window front, filtering by isCraftWindow — AppKit keeps offscreen windows for menus and tooltips, and ordering one of those front puts an empty frame on screen. That loop does not assume one window.

One thing to know before writing window teardown: #63 sets releasedWhenClosed = NO on every window, because the default (YES) deallocated the window on close and made reopen a use-after-free. Measured consequence — the window, its WKWebView, the DOM and the JS context all survive a close. That is what makes reopen restore state instead of reloading. When multi-window adds real window destruction, that is the line it has to pair with, and webview_recovery.forget(key) is the matching cleanup.

#64 left the hook in place

handleCreateWebView (webView:createWebViewWithConfiguration:...) is implemented and returns nil, routing the URL to the system browser. When craft.window.create exists, that method is where a real child window gets created — the delegate callback, the navigation action and the window features are all already in hand. It is a one-branch change, not new plumbing.

The remaining singleton surface, with numbers

Measured on main after round 2, so there is something to track against:

	count
global_*_bridge declarations in macos.zig	51
getGlobalWebView call sites	19
evalJS call sites (all resolve the one global webview)	80

bridge.evalJS is the real chokepoint: every reply and every event in the process goes through it, and it resolves one webview with no argument saying which. Per-webview reply routing is mostly one function's signature plus the request-context frame carrying the window — the 80 call sites do not each need a decision, because the dispatcher already knows which window it is serving by the time any of them run. That is the same trick #66 used, and it is why #66 was the prerequisite.

What round 2 did not fix

macos_window_events.zig still re-attaches one process-global NSWindowDelegate instance to each window. Untouched — nothing in round 2 needed it, and changing it without per-window event scoping would only move the problem.

#65's notification delegate is also process-global, and emitNotificationEvent goes through bridge.evalJS. So a notification response is delivered to whichever page the global webview resolves to. Correct with one window; it joins the routing work above rather than needing its own.