V10: localStorageExport saves the file under a UUID name instead of the requested filename

Ui.Vision Bug Reports
1

Chrome auto updated to 10.0.125 and some export capability stopped working. I suspect a beta was published wrongly given you have not officially released

Full summary by AI

Title: v10: localStorageExport saves the file under a UUID name instead of the requested filename
▎
▎ Versions: works in 9.6.1; broken in 10.0.x (seen on 10.0.56 through 10.0.125). Chromium 150.0.7871.128, Linux.
▎
▎ Repro: a macro with localStorageExport | test_export.csv | — intermittently the file lands in the download folder as .txt (the blob UUID) instead of test_export.csv. The macro log still reports ‘test_export.csv’ exported to the browser’s Downloads folder, so it looks successful. When it does work the name is correct but carries a (1) uniquify suffix.
▎
▎ Cause: the export now calls chrome.downloads.download({url: blobUrl, filename}). In current Chromium the filename option is ignored for blob URLs — I verified this directly: the download is accepted, completes without error, and lands as ., with the blob’s MIME type deciding only the extension (untyped → .txt, text/csv → .csv, application/octet-stream → no extension). The requested name never applies.
▎
▎ The correct name only ever arrives via the downloads.onDeterminingFilename listener, which suggests it with conflictAction: “uniquify” — hence the (1) suffix on successful exports. That listener only fires when activeDownloads is non-empty and the download id is registered, and that state is held in memory in the MV3 service worker. If the worker has been evicted, or the download isn’t registered in time, no suggestion is made and Chromium falls back to the URL-derived UUID name.
▎
▎ Suggested fix: don’t rely on service-worker-resident state for the filename — persist the pending map in chrome.storage.session, or go back to naming the file in the page (the pre-10.0.56 FileSaver/ path, which was not affected).
▎
▎ Since !errorignore reports the export as successful either way, this fails silently — any script that reads the exported file by name just finds nothing.

2

Issue confirmed, thank you for reporting it. → We will have a fix ready for this in 1-2 days!

Question: I am curious, how did you create this AI bug report? Did you let it scan the source code?

3

Thanks for acknowledging! Looking forward to the fix

On your question: short answer is not directly, I have a small fleet of profiles and some updated and some did not. It used the difference to get there of content

Claude long answer below

I pointed it at source, though not yours: Chrome keeps the unpacked extension in every
profile, so I have both the working and broken builds side by side at

/Extensions/gcbalfbdmfieckjlnblleoemohcganoc/9.6.1_0/
/Extensions/gcbalfbdmfieckjlnblleoemohcganoc/10.0.125_0/

It’s minified webpack output, but it greps fine, and popup.js in 9.6.1
still had readable names. So: repro from my own runs first, then the
agent diffed the two versions to find what changed in the export path.

Since I had it open, one thing that may be more useful than my original
theory. In 9.6.1, localStorageExport saved from the panel page:

FileSaver.saveAs(new Blob([text]), target)

i.e. an click, where Chrome always honours the name. From
10.0.29 it moved to the background - the panel does createObjectURL and
sends PANEL_DOWNLOAD_URL {url, filename} to the service worker
(PANEL_DOWNLOAD_URL doesn’t appear anywhere in 9.6.x). The SW handler
does this:

var n = {url: r.url};
r.filename && (n.filename = r.filename);
chrome.downloads.download(n, function (id) {
if (chrome.runtime.lastError || id === undefined) {
return r.filename
? chrome.downloads.download({url: r.url}, …) // name dropped
: reject(…)
}
resolve(true)
})

If the first call ever fails, the retry drops the filename and the
download succeeds under the blob UUID with nothing reported - which is
exactly what I see, intermittently and silently. Worth logging
chrome.runtime.lastError in that branch to see why the first attempt
fails (revoked blob URL, dead panel context, rejected name?). Note the
onDeterminingFilename listener can’t cover for it either: it only names
downloads registered in activeDownloads via prepareDownload, and this
path doesn’t go through it.

4

Thanks for the detailed answer! → Fixed in V10.0.133

The root cause was exactly what you found: current Chromium no longer honors the filename option of chrome.downloads.download() for blob: URLs.

On your Chromium 150/Linux setup the name degrades to the blob UUID; on Chrome 151/Windows we reproduced a milder variant where the basename survives but the extension gets rewritten from the blob’s MIME type (test_export.csv arrives as test_export.txt, and since the export blob was untyped, it was always .txt). Either way the requested name doesn’t apply, and the log still claimed success.