burrito.space / peek
experiments in a post-browser web
10
fork

Configure Feed

Select the types of activity you want to include in your feed.

docs(tasks): update status on the 3 remaining test failures

Document the state of the 2 real/flaky failures after the 2026-04-20
session's investigation attempts:

- Download popup cleanup: the existing will-download handler in
session-partition.ts has popup-closing logic but does not fire for
the test. Likely a session-partition mismatch for popup webviews.
- Tag widget ordering flake: commit 4d3f6cc7 isolated the test to its
own window but the full-suite flake still reproduces. Rules out
shared-window state leak as the cause. Real root cause elsewhere.
- NEW: page-layout maximize ordering flake (page-layout.spec.ts:407).
Passes in isolation but fails in full suite. First seen today.

burrito.space 4a739fb6 7680f643

+3 -2
+3 -2
docs/tasks.md
··· 23 23 - [ ] **v2 tile `cmd:execute:<name>:result` doesn't reach v1 extension-host subscribers.** (Will be obsolete after v1 removal — see [v1-removal-plan.md](v1-removal-plan.md). Documented here in case a quick patch is desired before that lands.) Tests in `smoke.spec.ts` (Command Execution describe — tag/untag/tagset/widget-update tests, ~7 of them) publish `cmd:execute:tag` from bgWindow with `expectResult:true, resultTopic:'cmd:execute:tag:result'`, then subscribe to that result topic. The tags v2 tile receives the publish, runs `executeTag()`, and tile-preload sends `tile:pubsub:publish` with the result topic — BUT the bgWindow subscriber never fires. Confirmed: 2026-04-17 added `cmd:execute:*` to tags' pubsub allowlist (in `b3a80b27`) and `waitForCommand` in beforeAll (in `daa4221a`); both necessary but tests still time out at 10s. Per Opus agent triage: bgWindow is `peek://app/background.html`, NOT in `extensionHostWindow`/`extensionWindows`/`getAllTileWindows()` — `extensionBroadcaster` skips it. bgWindow subscribes via legacy `IPC_CHANNELS.SUBSCRIBE` (`ipc.ts:4466`); the in-proc callback should fire on `publish()` but doesn't. That's the next concrete investigation. 24 24 - [ ] **Proton Pass extension doesn't autofill.** Still broken — doesn't show up in form fields, no autofill suggestions. Likely a content-script injection or messaging API gap in the webview/canvas setup. Reproduce: install Proton Pass extension, navigate to any login page, observe no inline autofill UI. (2026-04-17: agent triaged, 5 hypotheses in agent-ae11e03d worktree — extension gitignored so couldn't repro.) 25 25 - [x] **Download save failing.** Fixed 2026-04-17 commit `ab66d9e0` — cause (a): `setSavePath()` with existing path silently fails. Added `resolveUniqueDownloadPath()` in `session-partition.ts` that appends `-1`, `-2`, etc. before the extension. 26 - - [ ] **`target=_blank` download popup window not cleaned up.** `tests/desktop/download.spec.ts:151` expects `windowCountAfter ≤ windowCountBefore` after a download triggered through a popup-spawning link closes its popup. Consistently fails with one extra window remaining (off-by-one, 37 vs ≤36). Predates the 2026-04-20 pubsub/broadcaster work — full suite baseline had it failing too. Likely the download-handling path doesn't destroy the `about:blank` popup once the download redirects it out of existence. Investigation starting points: `backend/electron/session-partition.ts` (download handler), `backend/electron/ipc.ts` window-open handler for `target=_blank`, and whether `did-create-window` → download flow leaves the popup orphaned. 27 - - [ ] **Test ordering flake: `tags page widget updates dynamically when tag is added via command` (smoke.spec.ts:2010).** Passes in isolation (`yarn test:grep "tags page widget updates dynamically"`). Fails only inside a full `yarn test:electron` run, when ~148 tests have run before it and the test file's shared-app state has accumulated. Probably a state-leak from one of the preceding Command Execution tests that opens/closes the same canvas page URL key (`cmd-exec-test-page`) — the beforeAll re-opens but the prior instance's subscribers may still be live. Diagnosis cost: 2026-04-20 session confirmed it reproduces only in full-suite context, not under any isolated test:grep pattern. Fix direction: audit `beforeAll`/`afterAll` in the Command Execution describe for key-reuse assumptions, or switch the test suite to a unique URL-key per test rather than a shared one. 26 + - [ ] **`target=_blank` download popup window not cleaned up.** `tests/desktop/download.spec.ts:151` expects `windowCountAfter ≤ windowCountBefore` after a download triggered through a popup-spawning link closes its popup. Consistently fails with one extra window remaining (off-by-one, 37 vs ≤36). 2026-04-20 session investigation: the existing `will-download` handler in `backend/electron/session-partition.ts` already has popup-closing logic (branch 3: webview guest in popup window opened for a download URL). Adding a file-based diagnostic at the top of `ses.on('will-download', ...)` showed the handler NEVER fires in this test. Suspects: (a) the popup's canvas webview uses a session partition different from `profileSession` (where the handler is registered — session-partition.ts:58), so will-download fires on the other session with no handler attached; or (b) Chromium takes a different code path for popup-scoped downloads that skips will-download on the parent session. Next concrete investigation: grep for all `session.fromPartition` call sites that could be attached to a popup webview, and either register the download handler on ALL of them OR find the single partition the popup uses. 27 + - [ ] **Test ordering flake: `tags page widget updates dynamically when tag is added via command` (smoke.spec.ts:2010).** Passes in isolation. Fails only in the full `yarn test:electron` suite after ~148 tests. 2026-04-20 session attempted a fix (commit 4d3f6cc7) that gives test 2010 its own unique URL + key, closing the shared `cmd-exec-test-page` window and reopening a clean one for just this test, then restoring the shared window in `finally`. The Command Execution describe now passes 8/8 in isolation, and the test completes in 2.8s rather than 41ms (real work now happens). But **the flake still reproduces in the full suite** — 235 passing + tag widget still failing at 12.8s. Root cause not state on the shared window, then. Possible alternatives: (a) a non-window GLOBAL subscriber state leak from a much earlier test in some other describe block (audit all `api.subscribe` calls not scoped to `pageWindow`); (b) datastore items/tags from earlier tests pollute `loadAllTags()` or item queries in a way that breaks the assertion; (c) page.js at module-level installs a listener that persists across window reopens. Next investigation: run the failing test alongside its preceding test (the one that most recently opened a page window) via a cooperative grep pattern to narrow the triggering test. 28 + - [ ] **Test ordering flake: Page Layout Maximize `maximize command fills work area` (page-layout.spec.ts:407).** Passes in isolation (583ms). Fails in full suite at 15.1s (timeout). Surfaced 2026-04-20 run; not historically present. May be a new flake introduced by recent changes or a latent flake that only shows under specific suite ordering. Needs its own investigation, unrelated to the tag widget flake. 28 29 29 30 --- 30 31