4.6 KiB
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:
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:
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.