The browser design says how a second launch would bring a zone's open Firefox forward

[DevomB]

What was wrong

Firefox in a zone has no remote: the image leaves out both D-Bus and X11. So pressing the browser key (Alt+Shift+u), or the menu's b, a second time for a zone whose browser is open starts a second firefox. That instance finds the profile locked and says Firefox is already running. Nothing in the design said what should happen instead.

What changed

A section in docs/design/browser-and-graphics.md, "A second launch where Firefox is open". It is design only, nothing built:

• Where the window is known. Only dwl knows a window's zone (from its socket), its app_id, tags and focus order. A match on the app_id is sought only among one zone's windows.
• The key. It becomes a dwl focus-or-launch action: focus the zone's most recently used Firefox window, viewing its tag if needed, or launch as now. It needs no channel to dwl.
• The menu. It needs two things from dwl: a status line naming each zone's open app_ids, recorded by the chrome, and a one-line request file. dwl watches that file the way it watches the microphone and camera marks, in the session's 0700 runtime directory. The chrome keeps the launch, since the passphrase is asked on its terminal.
• Other cases. For another tag or monitor, dwl views the window's tag and never moves the window. A waiting zone's window comes forward unanswering, and the menu already says it waits.
• Not chosen. A zone-private D-Bus for Firefox's remote, and a Wayland protocol for the chrome.

How checked

Read against the current code. dwl's status already names the focused window's zone by socket (dwl-zone-borders.py, the zone status line). The key is untrustedcmd in build/desktop/dwl-config.h. The menu's b launches through kryptik-launch --ask in tools/desktop/kryptik-chrome. The section is wrapped at the document's width.