DevLobby 1.1.1

One crash, arriving five seconds after the thing that caused it.

What changed

Closing a browser pane no longer takes the window with it

Open a link in a pane of its own, close that pane, and five seconds later the
whole grid went black — every terminal, every page, gone from the screen. The
delay is the reopen window running out, which is what finally lets go of a
closed pane, so the crash arrived long after the click that caused it and
looked like nothing in particular.

Every <webview> method that reaches the guest — executeJavaScript among
them — begins by asking the element for the guest's id, and that throws once
the element has left the document. Synchronously, before there is a promise,
so a .catch() hung off the call never saw it. React runs a deleted
component's effect cleanups after it has removed the node, so a pane being
torn down was cancelling its Ctrl watcher against an element whose guest had
already gone — and an exception in a cleanup is one React has nowhere to put.
With no error boundary above it, it unmounts the root, and an empty root is a
black window.

Only a pane that had been somewhere could do it. The Ctrl watcher returns
early on about:blank, so a browser pane opened and never pointed anywhere
registered no cleanup to throw from — which is why a link, arriving with a URL
already on it, was the way to find this. Closing a whole grid with such a pane
in it did the same thing.

Nothing was actually lost when it happened: the shells kept running in the
main process behind the blank window. It was the grid you could no longer see.

Every injection now goes through one helper that turns that synchronous throw
back into the rejection the rest of the picker already knew how to ignore, and
npm run check:browser runs the real functions against an element that throws
the way a detached one does.

Download

devlobby-1.1.1-setup.exe	installs to your own user folder, so it never asks for admin, and adds Start Menu and desktop shortcuts
devlobby-1.1.1-portable.exe	one file, no install, no shortcuts

Windows x64. Your repositories, notes and layout live in %APPDATA%\DevLobby,
and upgrading over 1.1.0 leaves them alone.

If Windows blocks it

These builds are unsigned, so SmartScreen warns on first run — More info,
then Run anyway. Smart App Control, where it is enforced, judges each binary
by its hash and can refuse outright with "An Application Control policy has
blocked this file". Building from source and launching through devlobby.cmd
runs the same app through Electron's own signed binary, which that policy does
not object to:

npm install
npm run build
devlobby.cmd

The README has the screenshots
and the full tour.