1734903 - Possible blob? download issue with browser.download.improvements_to_download_panel

Status: RESOLVED DUPLICATE of bug 1731668

(Firefox :: Downloads Panel, defect)

Description

[rcandres]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

My firefox updated this morning, and I was in the process of downloading some backups from Mega.nz. Downloads after the update would show the progress bar on Mega.nz's download screen, but where the download would usually begin (in Firefox) after that bar completed, it never appeared and I didn't get my download.

I confirmed that the expected amount of network traffic occurs, so the file makes it to Mega's decryption buffer, but it's not getting saved/downloaded once the decryption is complete. Mega uses some form of blob to store the data instead of the usual download manager, so I'm guessing this is the source.

Turning off the experimental Firefox feature restored Mega's functionality, but it's also back to asking me what I want to do with various filetypes instead of downloading them, and I'm concerned about future compatibility if this bug gets into a release version without the option to turn it back off.

Note: I've tried everything short of deleting my entire profile, and only turning off the experimental download feature solved this problem. I'd tried resetting service workers, Mega's account reload, clearing all browser data, and only this helped.

Actual results:

The blob object was presumably prepared but failed to download properly once it was complete (although I won't rule out an earlier failure in the blob being created/allocated, given what fixed this, I'd say it's the experimental download setting).

Expected results:

The file should have appeared in the downloads manager and rapidly "downloaded" from a local blob object once Mega's actual download process was complete. It didn't ever appear and I can't find my file anywhere.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Downloads Panel' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Andrei Purice]

Hey rcandres,
Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 3

[rcandres]

I first retried my original test, as I’m doing this on my scratch computer.

A zip file downloaded properly, but a subsequent rar and a zip made by Mega failed to work (the progress bar completed in Mega, but the download never appeared in Firefox). The original file also failed again after this. Recalling that the issue occasionally did not show up for the first download, this is not surprising. (For the sake of full testing, a later reboot into my original profile of 93.0 with safemode turned back off failed again to download any files, but then disabling the download improvements option caused the downloads to succeed.)

I next tried rebooting Firefox in safe mode, and retried this test. None of the files downloaded properly this time, and Mega’s progress bar stayed at the nearly full mark for a while before displaying ‘Complete’ and disappearing.

After that, I created a new profile, with the only change being setting the browser.download.improvements_to_download_panel config to true (since I suspect that’s the issue). My original file (a .appimage launcher for the Prusa Slicer) downloaded, but neither the zip, the rar, or the folder-zipped-by-Mega downloaded. On a second try, I was able to download the .appimage file again this time, but the others still failed to download.

I also downloaded the nightly build of 95.0a1 and tried the same test (again, with only the single config changed). All of them downloaded properly this time, so it looks like something upstream may have fixed this?

Comment 4

[Micah [:mtigley] (she/her)]

This issue was originally caused by work done in Bug 1709129. The implementation there had it so we detected potential "spam" from a website, so it would allow the first download to happen but any subsequent ones would be blocked if they weren't evaluated to be user-initiated. There's still work we need to do for this so it was moved behind a separate pref in Bug 1731668, which was landed in 94.