From f161a5de742a81384a65e5b2befaf7b088385659 Mon Sep 17 00:00:00 2001 From: Jonathan Sykes Date: Fri, 9 Oct 2026 14:25:02 +0800 Subject: [PATCH] Record autosave comparison results and native storage limits --- plans/autosave-investigation.md | 50 +++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 plans/autosave-investigation.md diff --git a/plans/autosave-investigation.md b/plans/autosave-investigation.md new file mode 100644 index 0000000..d480741 --- /dev/null +++ b/plans/autosave-investigation.md @@ -0,0 +1,50 @@ +# Device autosave investigation — 2026-10-09 + +## Result + +No old=saves/new=does-not-save transition was reproduced. No product fix or breaking commit is justified by the available evidence. The interrupted run's commit b59fc72 already supplied the real-server harness, policy tests and phase comparison results; this continuation retained them and reran verification. + +The tested current frontend is the Phase 5 snapshot 21c1273 (parent of b59fc72), matching the requested regression scope. The shared `main` reference advanced during other queue work; this investigation did not change branches or incorporate those changes. Historical `autosave-main.json` represents main when the earlier run executed, not the subsequently advanced reference. + +## Exact behavior + +Both b77938a and Phase 5 have the same on-open gate: `saveBeforePlay:true`, video mode, no `preferStream`, web OPFS supported, and no existing saved copy. Save before playing defaults false. Audio-only and explicit streaming bypass the save. Successful saves become the playback source; failed saves fall through to streaming. + +Creating a playlist with a video or adding a video to an existing playlist calls `preload()` directly, including when autoPreload is false. On launch, autoPreload:true tops up playlists; pinned playlists top up even with the setting off. Enabling Auto-save through Settings persists the flag and starts playlist saves. The labels describe different policies; opening an arbitrary video with defaults never automatically saved in the old build either. + +References: frontend/app.js:2328 (on-open gate), :1946 (playlist policy), :1952 (pinned policy), :7107 (create playlist); frontend/views-core.js:1119 (Settings handler). + +## Evidence + +Fresh continuation commands: + +```sh +node perf/autosave.mjs --allow-unsupported-webkit --out perf/.tmp/autosave-recheck-current.json +node perf/autosave.mjs --frontend perf/fixtures/shell-1175f1a1d2c1 --asset-hashing 0 --asset-sync 0 --allow-unsupported-webkit --out perf/.tmp/autosave-recheck-old.json +node --test frontend/*.test.js +(cd server && bun install && bun run test) +``` + +Each build passed all 12 scenarios per engine. Chromium stored a complete real three-second H.264/AAC file, marked cachedIds and displayed it in Saved in all eight positive scenarios; the four negative scenarios did not save. Excerpts from both runs: + +```text +chromium open-default: PASS saved=false +chromium open-save-first: PASS saved=true +chromium playlist-add-setting-off: PASS saved=true +chromium settings-save-first: PASS saved=true +webkit settings-save-first: PASS UI/save guard only; OPFS unavailable +``` + +The Chromium settings-save-first scenario logged `Cannot read properties of null (reading 'addEventListener')` on both old and current builds despite completing the save. Assertions passing do not mean error-free UI; this shared error is a follow-up, not a newly introduced save failure. + +Linux Playwright WebKit has no native OPFS: its 12 passes establish UI/settings and capability-guard behavior only. No storage shim was used, and a genuine WebKit save remains unverified. The harness exits 2 without the explicit unsupported allowance. Thus the requested old/new/fixed comparison and a regression test failing on the allegedly broken build cannot honestly be supplied. + +Existing committed evidence under perf/results/autosave-*.json: Chromium Phase 1/2 all 12 cases, Phase 3/4/5 six positive cases, and both rollback flags six positive cases all passed. No failing phase tip exists in those runs. Frontend policy tests cover settings/pinning, duplicate saves and failed/paused saves remaining retryable. + +Continuation suites: 201 frontend tests passed; server 124 passed, two permitted worker failures due to Python ModuleNotFoundError: No module named yt_dlp. No other server failure. + +## Neighbor audit and iPhone follow-up + +Downloads, Saved, OPFS and download actions remain eager core assets. Export awaits feature:export; Share/External use the lazy facade. DirectMedia.hasSource returns false before its lazy module starts, which can select a server source instead of a paired source. P2P counts can initially appear empty before delayed startup. Neither was shown to prevent a server save. + +No runtime code changed; download bytes and startup behavior are unchanged. On the installed iPhone, verify the running build, Save before playing, audio-only and auto-save settings, then open a fresh video and separately add it to a playlist. Capture Downloads failure details, available storage, and Saved after relaunch/offline playback. Native iOS OPFS, quota/eviction and suspension during download require that device. A failing native sequence is needed to identify and fix the reported regression.