1892582 - Firefox tries to open .pkg bundle instead of downloading it

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[goran]

Attachment: A screenshot of what happens when trying to download a .pkg file.

Steps to reproduce:

On MacOS, in Firefox open a link to a .pkg bundle for download.

Actual results:

Instead of downloading the bundle installer, as every other browser does, Firefox tries to open it, resulting in gibberish text displayed on the screen.

Expected results:

A .pkg file should download to the user's computer. I am a software developer and have had at least 10 customers report this issue over the last few days.

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 correct in case you think the bot is wrong.

Comment 2

[Marco Bonardo [:mak]]

Could you please provide some example URLs where this happens?
I wonder if the server is overloaded and ends up serving the file with a text/plain mimetype, then Firefox will of course try to show it.

Comment 3

[goran]

Hi Marco,
Here is one such URL:
https://cdn.library.gorangrooves.com/products/plugins/mac/2.0.1/HandyDrums-Mallets-2.0.1.pkg

All files in question are being served from a CDN, such as the one above, and not from the main server. I don't think it has to do with a server overload. Keep in mind that this only happens with Firefox. They download the same files with no problem in other browsers. That's unfortunately been my solution: "Please use another browser, and the download will work."

I hope this helps.
Thank you.

Comment 4

[Marco Bonardo [:mak]]

This is what I see in the http header response:
content-encoding: gzip
content-type: text/plain
X-Firefox-Spdy: h2

I can reproduce it working as a download in Chrome, though I'm not sure why it would ignore content-type, maybe some kind of sniffing, or they are respecting the file extension more than the content-type.
Moving to File Handling for now, but it may be Network.

Anyway this should not be served as content-type: text/plain by the server, so there is a misconfiguration somewhere.

Comment 5

[goran]

Thanks, Marco.

Since this is being served from a CDN, I do not have access to configure how .pkg should be treated.

I hope that you guys can make some tweaks in Firefox so that it downloads anyway for anyone with a similar setup 😉

Thank you.

Comment 6

[:Gijs (he/him)]

(In reply to goran from comment #5)

I hope that you guys can make some tweaks in Firefox so that it downloads anyway for anyone with a similar setup 😉

Moving this to networking for evaluation.

Note that there is a (developing) spec for this type of thing, https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource - which has algorithms that improve/change detection for resources labeled as images or media types or HTML types - but nothing (AFAICT) for text/plain. Nonetheless, as comment 0 indicates, other browsers are doing some kind of sniffing, it would appear...

Comment 7

[Dennis Schubert [:denschub]]

This is more about a breakage on a specific site, so let's treat it as such. Moving this into our component and setting the right flags.

Comment 8

[:Gijs (he/him)]

(In reply to Dennis Schubert [:denschub] from comment #7)

This is more about a breakage on a specific site, so let's treat it as such. Moving this into our component and setting the right flags.

Is it? ISTM based on the comments that Gecko and Blink treat a pkg file sent with text/plain differently. That seems like a generic web compat issue in how we deal with mimetypes on the internet (even if the site is "wrong" and should be fixed, it feels similar to e.g. how HTML5 parsing deals with sites not doing the "right" thing when forgetting to close some nodes etc. - even if that's really a "site bug").

Comment 9

[goran]

In my naivety, I would expect browsers to treat any file online based on its extension, much like a file on a personal computer is treated by the OS. If you, say, take a ZIP archive and change its extension to .png, the system will treat it like an image and (unsuccessfully) try to open it in an image viewer.

Comment 10

[Dennis Schubert [:denschub]]

(In reply to :Gijs (he/him) from comment #8)

Is it?

This is, afaict, essentially, the same as bug 1875646, except that that one is a 7z and this one is a pkg. So both issues are site reports about the same underlying platform difference. This would still need a platform bug what we can block bug 1886142 against. There was a bit of added context in the triage meeting we just had, that it's bad not to have a platform issue filed for this, but of course I didn't note that in the comment.

If you want, we can move this back to a platform component and file a new Site Report for this so we can track it. Or we can create a new platform bug that describes the difference and ideally provides an isolated test case that doesn't rely on any specific site (maybe we can fake that by setting the content-type of an attachment as text/plain in Bugzilla?)

The reason to have this - or a clone - as a site report is so we can a) use the URL and page rank to calculate the platform bugs' score and b) keep it in our queue, because ideally, we'd also reach out to the site so they can fix their CDN configs for this.

Comment 11

[:Gijs (he/him)]

(In reply to Dennis Schubert [:denschub] from comment #10)

(In reply to :Gijs (he/him) from comment #8)
If you want, we can move this back to a platform component and file a new Site Report for this so we can track it. Or we can create a new platform bug that describes the difference and ideally provides an isolated test case that doesn't rely on any specific site (maybe we can fake that by setting the content-type of an attachment as text/plain in Bugzilla?)

I can file a separate platform bug. Sadly bugzilla won't do as it sends a nosniff header.

The reason to have this - or a clone - as a site report is so we can a) use the URL and page rank to calculate the platform bugs' score and b) keep it in our queue, because ideally, we'd also reach out to the site so they can fix their CDN configs for this.

OK, fair enough.

Comment 12

[:Gijs (he/him)]

(In reply to Dennis Schubert [:denschub] from comment #10)

(In reply to :Gijs (he/him) from comment #8)

Is it?

This is, afaict, essentially, the same as bug 1875646, except that that one is a 7z and this one is a pkg. So both issues are site reports about the same underlying platform difference. This would still need a platform bug what we can block bug 1886142 against. There was a bit of added context in the triage meeting we just had, that it's bad not to have a platform issue filed for this, but of course I didn't note that in the comment.

OK, fwiw, I didn't re-read 1875646 before my previous comment, but that bug has the server send no content-type at all, whereas here the server explicitly sends text/plain (which is obviously wrong). So it's not quite the same bug; the mimesniff spec has considerably more leeway for interpreting a content type in the former case than in the latter.

Edit: Argh, I made the same mistake as when I originally responded to that bug! That's embarrassing.

Anyway, I filed bug 1896460.

Comment 13

[Raul Bucata]

Verified this issue and still reproduces on Firefox Nightly

Tested with:

Browser / Version: Firefox Nightly 128.0a1 (2024-06-02) (64-bit)
Operating System: Windows 10 PRO x64