Download of certain mime types fail sometimes
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: cameron.frandsen1, Unassigned, NeedInfo)
References
Details
Attachments
(1 file)
|
4.47 KB,
image/png
|
Details |
neverendingdownload.PNG
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Steps to reproduce:
Using express, I wrote a server that used the following line of code:
res.attachment(name).sendFile(file.path, cacheOpts, deferred.makeNodeResolver());
Using firefox version 6.62, express 4.16.3, and node 8.11.0.
Downloading most filetypes worked 100% of the time. However, the file extension .4607 did not work 1 time out of 150. After updating to firefox 6.63, it started failed 4 or 5 times out of 10. Jpg also started failing 1 out of 50 times.
Changing the firefox version was the only thing that changed.
Actual results:
It would always attempt the download, but when it would fail, the download would say unknown time left - 0 bytes (0 bytes/sec). It would stay there indefinitely
Expected results:
It should have downloaded the file.
|
||
Comment 1•7 years ago
|
||
Hi,
Thank you for the feedback and for taking the time to report this.
Can you provide which version of Firefox and what OS are you using, as an official firefox version 6.62/6.63 does not exist? You can easily get the info if you type about:support and press Enter in a Firefox address bar.
Could you please retest using safe mode (https://goo.gl/AR5o9d), maybe even a new clean Firefox profile (https://goo.gl/AWo6h8), to eliminate add-ons or custom settings as a possible cause.
I'm also assigning a component to get a start on this, if considered wrong, please feel free to change it to a more appropriate one.
|
||
Comment 2•7 years ago
|
||
Can you provide a minimal testcase of your node/express server and how you run the downloads that fails with 63? And can you check with nightly and/or 64 release?
|
|
||
Comment 3•7 years ago
|
||
Closing as incomplete for now; with more info we could continue investigating.
|
Reporter | |
Comment 4•7 years ago
|
||
sorry, I don't know why I typed 6.62 or 6.63, it was just version 62 and 63. We saw it on both windows 10 and centos 7. I tried in safe mode, and it worked just fine. I will create a minimal testcase using github to show what we were seeing. I will get that up as soon as I can.
|
|
||
Comment 5•7 years ago
|
||
(In reply to cameron.frandsen1 from comment #4)
sorry, I don't know why I typed 6.62 or 6.63, it was just version 62 and 63.
I figured. If you could test more recent versions (65 is current release as of a few days ago, 66 is current beta, 67 is current nightly - https://nightly.mozilla.org/ ) that would be helpful.
We saw it on both windows 10 and centos 7. I tried in safe mode, and it worked just fine.
That safe mode works is particularly surprising. If you try a new profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ), and that also works fine, can you check what happens on that new profile if you copy the handlers.json and prefs.js files from the "broken" profile to the new profile? We might need to bisect what pref/setting it is that is causing the brokenness.
I will create a minimal testcase using github to show what we were seeing. I will get that up as soon as I can.
Great!
|
|
||
Comment 6•7 years ago
|
||
Closing this again due to lack of further info from the reporter.
Description
•