Window Switcher: I am able to drag the unsaved window into Saved Windows, and it breaks the UI until restart

During routine window and tab management I ended up in a situation where apparently different representations of the same window in different parts of Orion GUI have desynced. Tabs shown in affected window’s sidebar under Open tabs (further “open tabs”; these are the tabs I expect) became different from tabs listed for the window in the window toolbar menu (further “menu tabs”; these tabs seem wrong). Further actions made me suspect that the affected window with open tabs is technically no longer the window in window menu, even if they have the same label. The affected window became a “ghost” which cannot be operated on through the menu.

Symptoms and observations:

• This seems to affect one window so far.

• I don’t know exactly when it happened, because I don’t routinely check menu tabs, but possibly a few minutes ago when I renamed that window.

• Menu tabs for the affected window is partly a random selection of tabs from across other windows. These tabs were never in this window, they are super unrelated. may include tabs that were in this window at some point in the past, possibly prior to window rename and some other tab moves.

• Thsee don’t work in affected window:

  • Ctrl+Shift+T to undo closed tab doesn’t work
  • Bookmark N tabs doesn’t work

• When I was going through tabs in the affected window to bookmark and close them individually I encountered a number of glitches (gif below).

• This is interesting: hitting Cmd+T in the affected window does not create a new tab in that window, but instead creates a blank window with one tab. I can still create a new tab in the affected window by hitting the plus button, but broken shortcut makes me think the window is somehow glitched.

  • Even more interestingly, the newly added tab appears in both open tabs and menu tabs.

• I actually see no way to persist open tabs! All available actions (“create tab links”, etc.) operate on menu tabs only.

  • Duplicating the window creates a new window with menu tabs.
  • There’s the “take snapshot” option, which I did, but no idea if restoring it will restore the glitched window open tabs.

• Going to window menu -> Edit… to rename the window will open a new window.

  • It’ll have menu tabs in it.
  • …and yes, at this point there are two open windows with the same label but different sets of tabs.
  • The doppelgänger window that was just opened works normally, and could be renamed.
    • After the rename I now have the original affected window which does not show up in window menu. I don’t know if that window with those tabs will persist after browser is re-opened… Stay tuned
    • Interestingly, a tab added in the affected window (via the plus button, since Cmd+T doesn’t do the trick anymore) gets still appended to tab list of the other window, even though it now has a different name. Spooky action at a distance!
    • The affected/glitched window persists across browser restarts. Restarts address two glitches: tab click glitches shown below, and Cmd+T not working. However, all other glitches (including spooky tab action at a distance) remain, and the window itself still never appears in window menu list and cannot be operated on via that menu.

The underlying issue to me seems that representations of windows and their tabs shown in different areas of Orion GUI can go out of sync, perhaps especially during quick manipulations of tabs across multiple windows with many tabs. I could imagine a race condition when window data is written to disk, for example. Of course, I don’t know what I’m talking about… (But if yes I think I could take a performance hit in using Orion if it meant that window representations were always consistent, e.g. via a single blocking queue.)

Steps to reproduce:
I don’t know how to reproduce this, but it seems to have happened after the affected window was renamed. May be a red herring though.

Expected behavior:
Tabs shown in main window are the same as tabs shown in window menu and window with a given label in the window menu always exactly represents the open window with the same label.

Orion, OS version; hardware type:
Version 0.99.122-beta (WebKit 615.1.11.7)
MacBook Pro (macOS Monterey 12.6.2 build 21G320)
MBP ARM64

Image/Video:
There’s no obvious visual glitch, just different sets of tabs. Not at liberty to post full screenshots, part involves contract work.

This screenshot illustrates the point when open window had different tabs than the window in window menu with the same name:

This screenshot shows how “Bookmark these N tabs” doesn’t work in the glitched window:

This demonstrates glitchy tabs in the affected window:

What could help is if you provided a location where Orion stores runtime information on tabs and windows, which could be inspected for integrity issues in the event this happens again.

(A bonus would be if that location could be used to back up and restore the entire state of Orion, this would remove some worries regarding the possibility of another similar glitch and reduce the barrier to experimentation.)

OK, I’m doing some reverse engineering and I’m able to find references to lost windows—i.e., windows that are supposed to be created by naming/saving an anonymous window but don’t show up anywhere—in named_windows.plist and in browser_state.plist. Interestingly, the GUI doesn’t seem to be using those files as the source of window information. My guess is multiple sources of truth (some runtime cache, SQLite, plist, etc.) might be causing this issue.