experiments in a post-browser web
fix(windows): dismiss the overlay when any new window opens
The Windows switcher is alwaysOnTop overlay-role; without an
auto-dismiss path, hitting cmd+n (or any other shortcut/cmd that
spawns a window) opened the new window *behind* the switcher,
leaving the user staring at a stale overlay.
Subscribes the windows-overlay tile to `window:opened` (which
ipc.ts publishes whenever any tile-launched or page-host window
is created) and self-closes via window.close(). The existing
overlay close handler restores hidden windows and applies the
post-overlay focus target, so the just-opened window ends up
focused as expected.
Self-creation is filtered by comparing msg.id against our own
api.window.getInfo().id.
+21
-1
+2
-1
features/windows/manifest.json
+2
-1
features/windows/manifest.json
+19
features/windows/windows.js
+19
features/windows/windows.js
···
437
437
438
438
// Render windows
439
439
renderWindows();
440
+
441
+
// Dismiss the overlay if any new window opens (cmd+n, cmd palette,
442
+
// a tile-spawned window, etc.). Without this, the new window appears
443
+
// *behind* the overlay because we're alwaysOnTop. Filter out our own
444
+
// creation event so we don't immediately self-close on launch.
445
+
let ownWindowId = null;
446
+
try {
447
+
const info = await api.window.getInfo();
448
+
ownWindowId = info?.id ?? null;
449
+
} catch {
450
+
// No window.getInfo grant — best-effort; an extra "self" close is
451
+
// recoverable by re-invoking the windows command.
452
+
}
453
+
api.pubsub.subscribe('window:opened', (msg) => {
454
+
if (!msg || typeof msg.id !== 'number') return;
455
+
if (msg.id === ownWindowId) return;
456
+
debug && console.log('[windows] dismissing — new window opened:', msg.id);
457
+
closeWindowsView();
458
+
});
440
459
};
441
460
442
461
// Initialize when DOM is ready