0 byte downloads when downloading http files from https sites with "dom.block_download_insecure" set (the default)
Categories
(Firefox :: Downloads Panel, defect, P3)
Tracking
()
People
(Reporter: webmaistre.le.bilboquet, Unassigned)
References
Details
(Whiteboard: QA-not-reproducible)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0
Steps to reproduce:
Hi
Since version number 100 of firefox,
I obtain 0 byte files when downloadind from some websites. For examples
https://support.hp.com/ca-en/product/hp-probook-455-g8-notebook-pc/38228735/manuals
https://support.hp.com/ca-fr/product/hp-probook-455-g8-notebook-pc/38228735/manuals
https://endeavouros.com/latest-release/
IS there something we can do ?
Actual results:
0 byte files
Expected results:
full files
Updated•2 years ago
|
Comment 1•2 years ago
|
||
On which specific distribution/operating system? 0 bytes where? In the transfer itself? Or in the resulting file on some filesystem?
Reporter | ||
Comment 2•2 years ago
|
||
distribution/operating system? Mint Mate 20.3 Una
files are downloaded as 0 bytes in the download folder.
Thanks
Comment 3•2 years ago
|
||
I can't reproduce this with the provided links.
Since you said this works before Firefox 100, could you try to use mozregression to help us find out the regression range?
Or could you try to capture a http log?
Thanks.
Reporter | ||
Comment 4•2 years ago
|
||
I am probably not technical enough to pursue this dialog.
The fact is that at
https://support.hp.com/ca-fr/product/hp-probook-455-g8-notebook-pc/38228735/manuals
a page precedently referenced
I still get
a 0 octet (0 octets) file named c06688694.pdf
and
a 1,7 MB (1687552 octets) for the file named pdf_2096027_fr-FR-1.pdf one.
Obviously, Firefox decides not to trust URLs not beginning by 'https'
https://kaas.hpcloud.hp.com/pdf-public/pdf_2096027_fr-FR-1.pdf
http://h10032.www1.hp.com/ctg/Manual/c06688694.pdf
Here is the culprit HTML code :
<td><a href="https://kaas.hpcloud.hp.com/pdf-public/pdf_2096027_fr-FR-1.pdf" id="pdf_2096027_fr-FR-1" target="_blank"><span><i class="fa fa-file-pdf-o"></i></span> <span>Manuel de l'utilisateur Informations sur les réglementations, la sécurité et les conditions d'utilisation</span></a></td>
<td>1.61 MB</td>
</tr>
<tr>
<td><a href="http://h10032.www1.hp.com/ctg/Manual/c06688694.pdf" id="c06688694" target="_blank"><span><i class="fa fa-file-pdf-o"></i></span> <span>Manuel de l'utilisateur</span></a></td>
<td>7.83 MB</td>
</tr>
Thank you.
Roger
Comment 5•2 years ago
|
||
Can you create a http log?
See the HTTP Logging page for steps to capture HTTP logs.
If the logs are large you can create a zip archive and attach them to the bug. If the archive is still too large to attach, you can upload it to a file storage service such as Google drive or OneDrive and submit the public link.
Logs may include personal information such as cookies. Try using a fresh Firefox profile to capture the logs. If that is not possible, you can also put them in a password protected archive, or send them directly via email to necko@mozilla.com.
Reporter | ||
Comment 6•2 years ago
|
||
I just sent the log file to necko@mozilla.com.
Thanks
Roger
Comment 7•2 years ago
|
||
(In reply to Roger Gravel from comment #2)
distribution/operating system? Mint Mate 20.3 Una
Is Firefox installed as a Snap package, or is Firefox installed as a native Debian package?
Comment 8•2 years ago
|
||
Thanks for the log.
It looks like the http request is canceld by HelperAppDlg.jsm
.
2022-06-14 11:30:25.732413 UTC - [Parent 306812: Main Thread]: V/nsHttp Creating nsHttpChannel [this=7f92de9fbc00]
2022-06-14 11:30:25.732416 UTC - [Parent 306812: Main Thread]: E/nsHttp HttpBaseChannel::Init [this=7f92de9fbc00]
2022-06-14 11:30:25.732421 UTC - [Parent 306812: Main Thread]: E/nsHttp uri=http://h10032.www1.hp.com/ctg/Manual/c07012040.pdf
2022-06-14 11:30:25.732425 UTC - [Parent 306812: Main Thread]: E/nsHttp nsHttpChannel::Init [this=7f92de9fbc00]
...
2022-06-14 11:30:26.210034 UTC - [Parent 306812: Main Thread]: V/nsHttp nsHttpChannel::Cancel [this=7f92de9fbc00 status=80004004]
2022-06-14 11:30:26.210083 UTC - [Parent 306812: Main Thread]: V/nsHttp 7f92de9fbc00 called from script: resource://gre/modules/HelperAppDlg.jsm:310:22
The error code 80004004
is NS_ERROR_ABORT
, but I can't find where this is used in HelperAppDlg.jsm
.
I'd set the component to Downloads Panel
and let someone else have a look.
Comment 9•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #8)
Thanks for the log.
It looks like the http request is canceld by
HelperAppDlg.jsm
.2022-06-14 11:30:25.732413 UTC - [Parent 306812: Main Thread]: V/nsHttp Creating nsHttpChannel [this=7f92de9fbc00] 2022-06-14 11:30:25.732416 UTC - [Parent 306812: Main Thread]: E/nsHttp HttpBaseChannel::Init [this=7f92de9fbc00] 2022-06-14 11:30:25.732421 UTC - [Parent 306812: Main Thread]: E/nsHttp uri=http://h10032.www1.hp.com/ctg/Manual/c07012040.pdf 2022-06-14 11:30:25.732425 UTC - [Parent 306812: Main Thread]: E/nsHttp nsHttpChannel::Init [this=7f92de9fbc00] ... 2022-06-14 11:30:26.210034 UTC - [Parent 306812: Main Thread]: V/nsHttp nsHttpChannel::Cancel [this=7f92de9fbc00 status=80004004] 2022-06-14 11:30:26.210083 UTC - [Parent 306812: Main Thread]: V/nsHttp 7f92de9fbc00 called from script: resource://gre/modules/HelperAppDlg.jsm:310:22
The error code
80004004
isNS_ERROR_ABORT
, but I can't find where this is used inHelperAppDlg.jsm
.
I'd set the component toDownloads Panel
and let someone else have a look.
This is:
aLauncher.saveDestinationAvailable(result);
So presumably we hit:
which means that we don't get a file passed to us, ie result
is null for some reason.
If this is only happening for http
files, tbh I suspect something is going wrong with http mixed content blocking, but that should show UI.
Reporter: if you turn off dom.block_download_insecure
in about:config (ie set it to false), does that resolve the issue?
Reporter | ||
Comment 10•2 years ago
|
||
Thanks
I put false to dom.block_download_insecure
in about:config
and the files are downloaded.
Now, can someone explain the cause and the reason for this «bug» ?
Am I the only one complaining about this issue ?
Regards
Comment 11•2 years ago
|
||
(In reply to Roger Gravel from comment #10)
Thanks
I put false to dom.block_download_insecure
in about:config
and the files are downloaded.Now, can someone explain the cause and the reason for this «bug» ?
I don't really know yet. Broadly, what is supposed to happen is that we show the download panel with a note that the download was blocked because it was insecure (ie a secure, https website is redirecting/linking to an insecure (non-SSL/TLS/https) download). It sounds like that isn't happening in your case. I would also not expect a 0-byte file to be created either way.
Am I the only one complaining about this issue ?
This isn't the only case where we've seen people hit 0 byte files, but other causes for this seem to be slightly different and don't involve download blocking. Basically the 0 byte files can get left if the download breaks at a specific point, but the causes for this can be different.
Christoph, is anyone on your team able to investigate why http/insecure download blocking might be causing this to happen?
Comment 12•2 years ago
|
||
Reminder to self that maybe we want some more telemetry and/or logging (x-ref bug 1762416) so we get more insights into these types of failures.
Comment 13•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #11)
Christoph, is anyone on your team able to investigate why http/insecure download blocking might be causing this to happen?
Hey Tom, any chance you could take a look at this one?
Comment 15•2 years ago
|
||
bug 1686756 has an early analysis from Leli, not sure if it's still accurate.
Comment 16•2 years ago
|
||
So far I haven't been able to actually reproduce this issue with a zero byte file. I either get a very short file with a 404 page HTML or the dialog that asks if I want to use http: instead of https:. (I first enabled HTTPS-only mode.) Can some give me the right steps to reproduce this?
Comment 17•2 years ago
|
||
Hello! I have tried to reproduce the issue with firefox 104.0a1(2022-07-11) with Ubuntu 22.04, unfortunately I wasn't able to reproduce the issue on my end.
I will add the QA-not-reproducible tag since I could not reproduce the issue on my end following the STR provided in the description.
Comment 18•2 years ago
|
||
I tried to repro this in various ways some more but was unsuccessful. I also noticed bug 1754920 which is a bit similar.
We just really need the logging described in bug 1762416.
Some potential reasons that things break:
- https://searchfox.org/mozilla-central/rev/14781effaa15c12b1652beb75f021489567bad8f/uriloader/exthandler/nsExternalHelperAppService.cpp#2623-2629 fails (various reasons for that), which makes
SaveDestinationAvailable
cancel the request and do nothing. aFile
is null for some reason (e.g. filepicker that claims it was closed with "OK" but didn't provide a valid file reference)- a few other cases
But we can't tell what's happening because there is no logging in the browser console, http log, or anywhere else...
Comment 19•2 years ago
|
||
Still going to confirm this given the duplicate.
Comment 20•2 years ago
|
||
Also as a note https://searchfox.org/mozilla-central/rev/14781effaa15c12b1652beb75f021489567bad8f/toolkit/mozapps/downloads/HelperAppDlg.jsm#311-312 is basically just returning and if saveDestinationAvailable calls cancel there's no specific action taken.
Description
•