1747194 - Unknown content type dialog totally breaks when downloading files from Google Material Icons (due to sandboxed blob URLs)

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P2)

Description

[Shane Hughes [:aminomancer]]

STR:

1. Enable the unknown content type handler by toggling browser.download.improvements_to_download_panel to false in about:config.
2. Go to Google Material Icons
3. Click an icon
4. Click the download SVG button or download PNG button in the bottom right.

Expected:
The dialog has labels and radio buttons are selected by default, etc. as normally happens when downloading a file.

Actual:
Chaos ensues, resulting in no labels or icons being shown and no radio button being selected. Basically a ghost dialog. See my next comment below for a screenshot.

[Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: resource://gre/modules/DownloadUtils.jsm :: DU_getURIHost :: line 432"  data: no] DownloadUtils.jsm:432:25
    DU_getURIHost resource://gre/modules/DownloadUtils.jsm:432
    showStatusWithDetails resource:///modules/DownloadsViewUI.jsm:540
    _updateStateInner resource:///modules/DownloadsViewUI.jsm:718
    onChanged chrome://browser/content/downloads/downloads.js:1054
    onDownloadChanged chrome://browser/content/downloads/downloads.js:765
    _notifyAllViews resource://gre/modules/DownloadList.jsm:317
    DL_change resource://gre/modules/DownloadList.jsm:233
    DL_change self-hosted:1225
    D_notifyChange resource://gre/modules/DownloadCore.jsm:295
    refresh resource://gre/modules/DownloadCore.jsm:1020
    AsyncFunctionNext self-hosted:695

Uncaught 
Exception { name: "NS_ERROR_MALFORMED_URI", message: "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]", result: 2152398858, filename: "resource://gre/modules/HelperAppDlg.jsm", lineNumber: 510, columnNumber: 0, data: null, stack: "initDialog@resource://gre/modules/HelperAppDlg.jsm:510:25\nonload@chrome://mozapps/content/downloads/unknownContentType.xhtml:1:8\n", location: XPCWrappedNative_NoHelper }
​
columnNumber: 0
​
data: null
​
filename: "resource://gre/modules/HelperAppDlg.jsm"
​
lineNumber: 510
​
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
​
message: "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]"
​
name: "NS_ERROR_MALFORMED_URI"
​
result: 2152398858
​
stack: "initDialog@resource://gre/modules/HelperAppDlg.jsm:510:25\nonload@chrome://mozapps/content/downloads/unknownContentType.xhtml:1:8\n"
​
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
HelperAppDlg.jsm:510

Comment 1

[Shane Hughes [:aminomancer]]

Attachment: The dialog is missing labels and icons and doesn't have any radio button selection

Here's the screenshot

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Gijs could you please check why your patch regressed this?

Comment 3

[:Gijs (he/him)]

This happens because the blob URL is from a null principal...

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1747194 - don't allow sandboxed/null-principal blob URLs to completely break download flows, r?Mak,mhowell

Comment 5

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

Set release status flags based on info from the regressing bug 1053327

Comment 6

[Shane Hughes [:aminomancer]]

Wow that was fast, awesome. Thanks

Comment 7

[:Gijs (he/him)]

Note that after this bug is fixed the downloads from this particular site will go back to having a 'blob' source, which is unfortunate, but at the moment Firefox's frontend doesn't have access to the information to determine what the original URL is (if there is one; I haven't looked at the google material icons site in detail... it's possible they're using data URIs or other completely-opaque contexts, rather than just an <iframe sandbox> that they load a google URL into). The breakage is being caused by assuming that information is always available. I filed bug 1747240 to see if we can get (gecko to expose...) the information somehow, but obviously we should unbreak downloads stuff as a first step...

We'll continue to display an origin for sites that generate their own blob URLs directly (ie bug 1053327 stays fixed for some (most?) sites, but not for this one).

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/864e2bc98cf4
don't allow sandboxed/null-principal blob URLs to completely break download flows, r=mak

Comment 9

[Shane Hughes [:aminomancer]]

Idk if this information is valuable, but this site is super weird and I have no idea how or why. Until a couple months ago, this site had some other weird issues in Firefox. I don't think the site changed much, it presumably just has to do with Firefox's downloads changes. Left clicking the download buttons used to do nothing, I had to middle click them to open the raw SVG in a new tab (the button's just an anchor element with href="https://fonts.gstatic.com/s/i/materialicons/info/v20/24px.svg"), and then File > Save as..., and from there, after saving once, the download would fail with an error badge appearing on the downloads toolbarbutton. Then after saving a second time, it'd work. I took to just copying and pasting the markup until this week I saw left click was working again.

Comment 10

[Shane Hughes [:aminomancer]]

Oh and those buttons have heavily minified mouse event handlers so I basically stopped there. I don't expect Google's site to work correctly since it's so unusual but just to visually handle the dialog gracefully so it doesn't look like you're getting attacked by a wild missingno

Comment 11

[:Gijs (he/him)]

(In reply to aminomancer from comment #9)

Idk if this information is valuable, but this site is super weird and I have no idea how or why.

The downloads aren't just presented to the browser as "normal" links to http/https resources, but use blob. They also appear to use links that are styled as buttons, and those links have an https-based href but they use JS events to intercept the navigation to that link and do something else (forcing a blob download) instead. Goodness knows why they have all this complexity when <a href=... download> would have worked perfectly well.

Until a couple months ago, this site had some other weird issues in Firefox. I don't think the site changed much, it presumably just has to do with Firefox's downloads changes.

"citation needed"

Considering this regression (ie from comment 0) was unrelated to "Firefox's downloads changes", just to me fixing a bug relating to the display of blob URIs in the Unknown Content Type dialog, I don't think this is all that likely. It also seems like you underestimate how often google web properties change (without necessarily showing obvious user-visible visual changes)...

Left clicking the download buttons used to do nothing, I had to middle click them to open the raw SVG in a new tab (the button's just an anchor element with href="https://fonts.gstatic.com/s/i/materialicons/info/v20/24px.svg"), and then File > Save as..., and from there, after saving once, the download would fail with an error badge appearing on the downloads toolbarbutton. Then after saving a second time, it'd work. I took to just copying and pasting the markup until this week I saw left click was working again.

If you wanted to dig into this further, it'd probably help if you used mozregression --find-fix to figure out when the left-click stuff stopped being broken. That might give a clue. If I had to guess, perhaps the mixed content download blocking (from bug 1614969, again, unrelated to "Firefox download changes") had something to do with it. But perhaps you'll find that old builds now also work, and so the mozregression work won't actually find a usable range, because the site did in fact change.

Comment 12

[Shane Hughes [:aminomancer]]

I didn't have a good reason for assuming that, just that the change in button behavior roughly coincided with when all these changes to the downloads system started. But anyway here's the range https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9a94133c2125269f51de6606c21cba01ea34f9a5&tochange=18c51c48110a83f2f3d7caec678068643ca5eb33

Comment 13

[Shane Hughes [:aminomancer]]

I just tested setting that pref privacy.partition.bloburl_per_agent_cluster to true btw, and it indeed breaks left click on those buttons, so I guess that's the fix

Comment 14

[:Gijs (he/him)]

(In reply to aminomancer from comment #13)

I just tested setting that pref privacy.partition.bloburl_per_agent_cluster to true btw, and it indeed breaks left click on those buttons, so I guess that's the fix

Yeah, looks like it'd be worth commenting in bug 1667348 that this google site uses the same sandboxed iframe technique to download blobs.

Comment 15

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/864e2bc98cf4

Comment 16

[Monica Chiorean]

I was able to reproduce the issue on Win10 using build 97.0a1 (20211221214151) and steps from description.
Verified as fixed on Win10 / Mac 10.13 / Ubuntu 20.4 using build 97.0b5 (20220118185733).