Repository navigation
fix(browser): stage Chrome's downloads in the session profile - #960
Merged
Merged
Conversation
Browser.setDownloadBehavior is browser-wide, so files Chrome downloads on its own, with no page and no download event, landed in the user's Downloads under a GUID and were never renamed (macOS and Windows runners, after #959 switched the optimization guide's model downloads off). Chrome now writes into a staging folder inside the session's ephemeral profile. Only a download a page announced moves to Downloads, under its reserved name; anything else stays in staging and is deleted with the profile. Across filesystems or volumes the move falls back to a copy under a hidden .part name, renamed once whole, reusing profilestore's copy helper and cross-device seam, now exported.
This was referenced Oct 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
TestChromeDownloadsLandInDownloadsAndThePageStaysstill failed on macos-latest after #959 (run 40686685056 on #955): Downloads held four GUID-named files beside the six downloads.Browser.setDownloadBehavioris browser-wide, so whatever Chrome downloads on its own, with no page and nodownloadWillBegin, lands in the download path under its GUID and is never renamed. #959 switched off the optimization guide's model downloads; another background download still lands.What changed
lich-downloadsinside the session's own profile dir (ephemeral, removed on close), never the user's Downloads.begin) into Downloads under its reserved name. Anything else stays in staging and goes with the profile.ERROR_NOT_SAME_DEVICEthe move copies to a hidden.<guid>.partbeside the target, keeps the mode, renames it into place, then removes the staged file. A half-copied file never carries the final name.profilestore.copyFileandcrossDevice(the build-tagged seam) are exported asCopyFileandCrossDeviceand reused, not duplicated.docs/ceilings.md(downloads bullet) anddocs/browser-tab.mddescribe staging, the cross-disk copy and that background files take the profile's disk until close. The CHANGELOG entry stays true, so it is unchanged.The #959 disabled features stay; no new ones were added. The exact feature behind the remaining GUID files was not identified.
Tests
downloads_test.gocases plant the GUID file in staging, and the failed-rename case expects the staged path. Their assertions on names,(1)collisions and overwrites are unchanged.go test -count=20 -run 'TestChromeDownloads|TestChromeOpenAndNavigateToAFile' ./internal/browser/on Linux: 20/20 before, 20/20 after (the failure only showed on macOS and Windows runners).gofmt,go vet ./...,go test ./...green; cross-compile loop for linux, darwin and windows clean.