1754920 - A blocked insecure (mixed content) download that we intend to open once downloaded, results in a 0-byte file and download panel oddness

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Daniel Veditz [:dveditz]]

When you download an insecure (http:) file from a secure (https:) document this gets blocked by the mixed content blocker. That's expected and fine. NOTE: disable HTTPS-ONLY mode or you will run into a different issue (see bug 1686756).

The blocked download is reported in the download panel: there is a red warning icon and the text "File not downloaded: Potential security risk". So far, still fine. If you click on the file in the toolbar download panel it expands and gives you the same text plus a longer explanation.

#1: the expanded panel also has two buttons, "Open" and "Remove File". Neither of these logically make any sense for a file that was not downloaded.

#2: If you look at the file in Finder you will find that something is there! Like bug 1686756 this file is reported as "Zero bytes" in finder, or "0" using ls -l from a shell

If you click the "Remove File" button the empty file (that the dialog says wasn't downloaded) is removed. I guess that's OK?

#3: if you click the Open button the file opens! If you look in the directory the formerly-empty file is no longer empty! Where did this come from?

#4: the entry in the panel loses the red warning text and now looks like any other successful download. No hint it was downloaded insecurely.

Test case to reproduce the above:
0. make sure HTTPS-only mode is disabled

1. Browse to https://blog.chromium.org/
2. in the right column click the "Feed" button. This is an insecure http: link to an atom.xml file served with Content-Type: application/atom+xml; charset=UTF-8
3. you get the panel with the blocked download error message, and from here can observe #1-#4 above.

Comment 1

[Daniel Veditz [:dveditz]]

Tagging Gijs to make sure he sees this since he's been making some changes here and might already know what's going on.

Comment 2

[:Gijs (out for now; he/him)]

I'm pretty confused because the last time I saw this UI the labels and styling were different, I think? But this entire feature (ie mixed content download blocking) has been implemented by the DOM security team, and shouldn't have changed as part of the downloads project, so passing to Christoph and co for initial triage as to what's happening here. I agree that the "open file" label is confusing and wrong, and I haven't seen that before. Do we know if this is a regression? Does this just happen for XML files, or something?

Comment 3

[:Gijs (out for now; he/him)]

OK, some quick testing later, a few notes:

1. this works correctly (well, at least #1 wasn't an issue, I didn't bother checking the other parts of the report) with downloads improvements turned off and clicking "save file" in the dialog that comes up asking what to do with the file, but...
2. the same problem was reproducible before if in the dialog you selected "open in Nightly" as the action;
3. all of this works fine when clicking e.g. the links on https://www.thinkbroadband.com/download (on current nightly, with downloads improvements turned on).

So I expect it is default-action-for-XML-related, and this only happens for files set to automatically open. In that case I expect this particular testcase will appear addressed in tomorrow's nightly given the fix for 1753004 has finally landed and stuck. The underlying issue will still be there, however...