fix(desktop): open the window without waiting for the pane-sites clean-up
Links
- Plain: T-1197, T-1198 ("Desktop 2.0.5 launches without a window on macOS")
- Regressed in #9221 (Chrome extensions and passkeys in the browser pane)
Summary
- Startup no longer waits on the browser-pane migration's clean-up step. The window opens first, and the clean-up runs in the background.
- The cookie copy stays before the window, so pane sites stay signed in on first load.
Why / Context
#9221 added movePaneSitesOnce, which startup awaits before the window is created. After it copies pane cookies to the pane session, it calls appSession.clearData({ origins }) to remove those sites from the app session. That call goes through the whole app session (HTTP cache, Service Worker storage, IndexedDB…), so its cost grows with the partition size, not the origin count. Nothing bounds it.
Reproduced in real Electron 44.10 with a clone of a real 2.6 GB Partitions/superset (1.1 GB Cache, 1.0 GB Service Worker):
clearDatawith 1,075 origins: 21 s. With 4,075 origins: also ~21 s.- Dev desktop on that profile (marker
n/n, no.cleared), old code: window after 25 s, at the same moment.clearedis written. So the window is held until the clean-up finishes.
Both reporters got past it by creating pane-cookies-copied.cleared, which skips only that step. So on their profiles clearData did not finish at all, every launch. I could not make it hang forever locally. Either way the window must not depend on it.
How It Works
movePaneSitesOncenow only copies: it reads the app session's non-Paradev cookies, sets them on the pane session, and writespane-cookies-copiedascopied/total. It skips if either marker exists (users who applied the workaround keep working).- New
clearMovedPaneSitesOncedoes the clean-up. It runs only after a full copy, and writes.clearedonly afterclearDataresolves.index.tscalls it aftermakeAppSetup(window created) withvoid …catch(log). - Safe if cut off: the clean-up only touches the app session, never the pane session. If the app quits mid-clear,
.clearedis not written and the clean-up runs again next launch. The copy marker is still written only after every cookie was tried, as before.
Manual QA Checklist
- Dev desktop, crafted profile (cloned 2.6 GB app partition,
pane-cookies-copied=2924/2924, no.cleared). Before: window (renderer page target on this worktree'sDESKTOP_VITE_PORT, seen over CDP) after 25 s. After: window after 1 s. The clean-up still finished in the background and wrote.clearedat 26 s. - Fresh dev profile: window opens, migration markers written (
0/0+.cleared). - Cookie copy cost measured in Electron: 2,923/2,924 cookies in 0.2 s, so it stays on the startup path.
Testing
bun test src/main/lib/browser/move-pane-sites.test.ts. A new test "finishes the copy without waiting for the old sites to clear" (clearOldSitesnever settles) failed on the old code (Received: "hung"). After the split, a test covers copy without clear, plus a clean-up cut off part way that runs again without re-copying. 5/5 pass.bun run typecheck(apps/desktop): passbun run lint:fix: clean
Workaround for users still on 2.0.5 / 2.0.6
Quit Paradev, then:
touch "$HOME/Library/Application Support/Superset/pane-cookies-copied.cleared"
Then open Paradev again. No data is deleted. The app session keeps some old pane-site data that "Clear browsing data" won't reach.
Known Limitations
- I did not find the exact profile state that makes
clearDatanever resolve (vs. take ~20 s). The fix removes the dependency instead of tuning around one cause.
Summary by cubic
Fixes startup blocking in the desktop app where the pane-sites migration's clean-up step could delay the window by 20+ seconds or prevent it from opening on large profiles (T-1197, T-1198, regressed in #9221).
The cookie copy — fast at roughly 0.2 s for ~3,000 cookies — stays on the startup path so pane sites remain signed in on first load. The slow clearData over the whole app session now runs in the background after the window is created and retries on the next launch if it gets cut off.
Behavior notes
- The clean-up only touches the app session, never pane cookies.
- Profiles that already wrote the
.clearedmarker keep skipping both steps.
Summary by CodeRabbit
- Bug Fixes
- Improved the handling of browser site data when moving pane data between sessions. Old site data is cleared only after copying completes successfully.
- If clearing old site data fails, cleanup can be retried without copying the data again.