**Note** from Bead: Chrome Tab Manager · [canonical source](https://redfish.acequia.io/guerin/.agents/6966f467-4993-4cc0-b148-72bb348d5990/2026-06-12/notes/snss-parse-and-framing-limits.md) · session 2026-06-12 · discussion: Talk: Chrome Tab Manager
Two working concepts for the chrome-tab-manager bead.
## 1. Reading tabs-by-window from Chrome's SNSS files Chrome persists open tabs to undocumented **SNSS** binary files in the profile's `Sessions/` dir: `%LOCALAPPDATA%\Google\Chrome\User Data\Default\Sessions\Session_*` (and `Tabs_*`). Format: 4-byte magic `SNSS` + int32 version, then a stream of commands — each `uint16 size`, then `size` bytes whose first byte is the command id. Commands we use: - `SetTabWindow` (0): `int32 window_id, int32 tab_id` → window membership. - `SetTabIndexInWindow` (2): `int32 tab_id, int32 index` → tab order. - `UpdateTabNavigation` (6): pickle `[tab_id][nav_index][string url][string16 title]…` — current URL = **highest nav_index** seen. - `WindowClosed` (4), `SetActiveWindow` (20). - Pickle strings are int32-length-prefixed and **padded to a 4-byte boundary**; string16 is UTF-16LE, length in chars. **Locking gotcha:** Chrome holds an **exclusive** lock on the live `Session_*` file — `cp` fails ("Device or resource busy") and even .NET `FileShare.ReadWrite` shared-read is refused. Fall back to the newest *readable* `Session_*` (usually only minutes stale). For exact-current state there's no file route: relaunch Chrome with `--remote-debugging-port=9222` and read `http://localhost:9222/json`. Window-grouping is **reconstructed**, not authoritative — derived from `SetTabWindow`. A tab mid-navigation can show a slightly older URL. Parser: `C:\Users\steph\Downloads\parse_snss.py` (stdlib only) — to be promoted into `skills/` as the slideshow-maker's front half.
## 2. iframe framing limits (slideshow constraint) Many sites refuse to render in an iframe via `X-Frame-Options: DENY/SAMEORIGIN` or CSP `frame-ancestors`. Observed in window #10: Amazon, jwt.io, Google properties, some `simtable.com` pages. Same-origin acequia/gsd/redfish pages frame fine. The slideshow handles this with a **heuristic load-timeout overlay**: if the iframe doesn't fire a usable `load` within ~2.5s, show a "site refuses framing" panel whose only action is the **open-in-new-window** escape hatch (`window.open(url,'_blank','noopener')`). This is heuristic, not detection — a genuinely slow page can trip it; the iframe keeps loading underneath. A cleaner future signal: a HEAD/`fetch` preflight reading the headers, or a server-side proxy that strips frame-busting headers (only for same-trust origins).