Inconsistent MIME type handling across platforms, failing to open downloaded file on Windows

VERIFIED FIXED in Firefox -esr60



10 months ago
7 months ago


(Reporter: grmat, Assigned: Paolo)


(Blocks: 1 bug, {regression})

60 Branch
Firefox 63
Windows 10
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox-esr52- wontfix, firefox-esr6062+ verified, firefox60 wontfix, firefox61+ verified, firefox62+ verified, firefox63+ verified)


(Whiteboard: [no-nag])


(1 attachment)



10 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180518073241

Steps to reproduce:

0. Start Linux
1. Visit (or any web site that offers downloads for different content-types and file extensions; or set one up)
2. From the lower examples, where the column "what should happen" reads "offer to Save to disk" or "Save to disk or open application", select one file without a file extension, e.g. (x-foo/x-bar; "file")
3. Select a program to open the file with
4. repeat on Windows

Actual results:

after step 3, Firefox on Linux succeeds to open the file with the selected program. On Windows, the exception "fileExtension is null" (at DownloadIntegration.jsm:602) is printed to the Browser Console. The function there checks whether the file is an executable and the user should be warned, checking the file extension, which is null.

As a result, Firefox on Windows will download the file to the temporary folder, but not open it with the selected program.

I was able to workaround this issue by manually editing the "handlers.json" in the profile folder and add an "extensions" array containing a file extension string to the specific mimeType object, e.g. like this:

"x-foo/x-bar": {
    "action": 2,
    "handlers": [
            "name": "NOTEPAD.EXE",
            "path": "C:\\Windows\\system32\\NOTEPAD.EXE"
    "extensions": [
    "ask": true

This way, Firefox will append ".txt" to the filename and not run into the fileExtension is null exception.

Expected results:

Consistent behaviour across the platforms. If the content-type is given, FF should not rely on the file extension under Windows. Also, the user is not notified about the error if they don't have the browser console opened.

Comment 1

10 months ago
To add to the confusion, another issue:
The above mentioned handlers.json seems to be only updated for a mime-type at first occurrence. E.g. if a file "foo.txt" with type "x-foo/x-bar" is downloaded in a fresh profile, firefox will add the "txt" extension to the json object. If the file is downloaded *without* the extension in a fresh profile, and later a file with the same mime-type but *with* a file extension, Firefox won't add the extension to the json. IMHO that means that it is cyrrently possible to "break" a user profile for each mime type.


10 months ago
Summary: Inconsistent MIME type handling across platforms, failing to open donloaded file on Windows → Inconsistent MIME type handling across platforms, failing to open downloaded file on Windows
I have reproduced the steps given successfully. The presumed issue is that the downloaded file is not opened if the user chooses to open the "x-foo/x-bar" type file with a specific program and/or the issue is that the user user is not warned that the file does not have an extension, so it won't be opened. 
Furthermore, the file can successfully be opened (with text readers, in this specific case) afterwards from the destination is was downloaded to.

I will set this issue's component on File Handling and will let the developer decide whether this is an issue or not.

grmat, please log the second issue in a separate bug. Only one issue can be addressed in one bug.

Thank you for your contribution!
status-firefox60: --- → affected
status-firefox61: --- → affected
status-firefox62: --- → affected
Component: Untriaged → File Handling
Flags: needinfo?(grmat)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64


9 months ago
Assignee: nobody → paolo.mozmail
Blocks: 1369771
Ever confirmed: true
Flags: needinfo?(grmat)
Keywords: regression
Priority: -- → P1


9 months ago
Duplicate of this bug: 1391608
status-firefox60: affected → wontfix
status-firefox61: affected → fix-optional
status-firefox62: affected → fix-optional
status-firefox63: --- → affected
status-firefox-esr52: --- → wontfix
status-firefox-esr60: --- → affected
Comment hidden (mozreview-request)

Comment 5

9 months ago
Comment on attachment 8987837 [details]
Bug 1465458 - Fix launching downloads without a file extension on Windows.

how hard is to make a test for this?
Attachment #8987837 - Flags: review?(mak77) → review+

Comment 6

9 months ago
Not trivial, but it can be done with mock objects. I'll file a bug.


9 months ago
Flags: qe-verify+

Comment 7

9 months ago
Pushed by
Fix launching downloads without a file extension on Windows. r=mak


9 months ago
Blocks: 1471981

Comment 8

9 months ago
Last Resolved: 9 months ago
status-firefox63: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
This issue is fixed in Nightly v63.0a1 (2018-06-29). Tested on Windows 10 x64.
status-firefox63: fixed → verified
Flags: qe-verify+

Comment 10

9 months ago
Thanks for the quick verification!

Comment 11

9 months ago
Comment on attachment 8987837 [details]
Bug 1465458 - Fix launching downloads without a file extension on Windows.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:

This is a simple code correctness fix for an issue that was also reported a while ago in bug 1391608. A workaround exists by opening the folder that contains the document and launching it from there, which I guess is the reason why we had this reported only twice in a year.

ESR 52.9 is also affected since bug 1369771 was uplifted recently to support bug 1468217. I recommend taking this code correctness fix as a ride-along for a possible dot release.

User impact if declined:
Unable to open documents without a file extension on Windows.

Fix Landed on Version:

Risk to taking this patch (and alternatives if risky): 
Low risk, it just restores the correct behavior.

String or UUID changes made by this patch: 
Attachment #8987837 - Flags: approval-mozilla-esr60?
Attachment #8987837 - Flags: approval-mozilla-esr52?
Attachment #8987837 - Flags: approval-mozilla-beta?


9 months ago
status-firefox61: fix-optional → wontfix
status-firefox-esr52: wontfix → affected
tracking-firefox62: --- → ?
tracking-firefox-esr52: --- → ?
tracking-firefox-esr60: --- → ?
Regression since 55 with a pretty easy workaround, but, I can see the point of uplift for 62, and we're still early in 62 beta.
tracking-firefox62: ? → +
Comment on attachment 8987837 [details]
Bug 1465458 - Fix launching downloads without a file extension on Windows.

Verified in nightly, let's take this for beta 5.
Attachment #8987837 - Flags: approval-mozilla-beta? → approval-mozilla-beta+


9 months ago
status-firefox61: wontfix → affected
tracking-firefox61: --- → ?
Might be nice to add an automated test here too if possible.
tracking-firefox61: ? → +
tracking-firefox63: --- → +
Flags: qe-verify+
Flags: in-testsuite?
Comment on attachment 8987837 [details]
Bug 1465458 - Fix launching downloads without a file extension on Windows.

Approved as a ride-along for 61.0.1 too.
Attachment #8987837 - Flags: approval-mozilla-release+

Comment 16

9 months ago
status-firefox62: fix-optional → fixed

Comment 17

9 months ago
status-firefox61: affected → fixed
tracking-firefox-esr60: ? → 62+
Platform: Windows 10 x64
- I’ve reproduced this issue on Firefox 62.0a1 (2018-05-30.
- I’ve successfully managed to open a file without extension on Firefox 62.0b5 (20180702164905) and Firefox 61.0.1(20180704003137).
status-firefox61: fixed → verified
status-firefox62: fixed → verified
Flags: qe-verify+

Comment 19

9 months ago
This is now verified on Release, can we land this as a potential ESR 52 ride-along too? It fixes a bug that is new in 52.9, not present in the previous 52.8 version. Even if 52 is supported for only two more months, it would be good to have this landed, just in case we make a dot release in the meantime.
Flags: needinfo?(lhenry)
We can take this if and when we prepare a dot release.
Flags: needinfo?(lhenry)

Comment 21

9 months ago
I'm asking because I get release tracking alert e-mails, but if we don't plan to take any action here, I'll just ignore them.
This should silence the alerts.
Whiteboard: [no-nag]

Comment 23

9 months ago
Cool, thanks! :-)
Comment on attachment 8987837 [details]
Bug 1465458 - Fix launching downloads without a file extension on Windows.

Approved for ESR 60.2.
Attachment #8987837 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+

Comment 25

8 months ago
status-firefox-esr60: affected → fixed
Flags: qe-verify+
This issue is still reproducible in ESR60 (v60.1.0esr) while the change is in the build. The error "fileExtension is null" is displayed in the Browser Console. 
@Paolo Amadini, do you know why this happens?
Flags: needinfo?(grmat)
Which exact build are you testing?  The 60.1.0esr release predates that change.
Flags: needinfo?(daniel.bodea)
I took the change set from comment 25 (bb310ef154f7), installed the latest ESR60 build (Build ID: 20180621121604) and I made sure that the fix change set is inside the browser's pushlog, and it seems like it is:
push date: Sun Jul 15 16:47:34 2018 +0000	
bb310ef154f7	Paolo Amadini — Bug 1465458 - Fix launching downloads without a file extension on Windows. r=mak, a=RyanVM"

Then I tried the STR from comment 0 on Windows 10:
1. Start broser (v60.1.0esr).
2. Open "".
3. pen Browser Console (CTRL+SHIFT+J);
3. Click on the "file" links that coresponds to the "x-foo/x-bar" (without extension).
4. Choose the "Open" option, not the "Save" option.
5. Notice that the pop-up to choose a program to open with will not appear AND an error will be displayed in the Browser Console:
"fileExtension is null  DownloadIntegration.jsm:602
	launchDownload resource://gre/modules/DownloadIntegration.jsm:602:1
	InterpretGeneratorResume self-hosted:1257:8
	next self-hosted:1212:9
	launch resource://gre/modules/DownloadCore.jsm:677:12
	_succeed resource://gre/modules/DownloadCore.jsm:545:7
	InterpretGeneratorResume self-hosted:1257:8
	next self-hosted:1212:9

This issue does not occur in the case of the 3 main version of Firefox (Release, Beta, Nightly).
Is it the wrong build?
Flags: needinfo?(daniel.bodea)
A build from June 21 is definitely the wrong one, yes.
Flags: needinfo?(daniel.bodea)
I will wait for the next ESR60 build to verify the fix.

Thank you. 

P.S. I will leave the NI? request on my name so I'll be notified.

Comment 31

8 months ago
:danibodea you pinged me, but I'm not sure what you need from me. Could you please clarify or is it settled already?
Flags: needinfo?(grmat)
There was a confusion related to which ESR60 build contains the fix because I somehow thought that the lase one released had it. However, it appears I'll have to wait for the next ESR60 build release, since there isn't a working build in CI. Thank you.

I'll still keep the NI? request on my name until I verify the uplift.
There's tons of working CI builds. Just grab the most recent from Treeherder.
I have used the following build:
This issue is also fixed in ESR60 (v60.1.1esr). Uplift successful. 
Thank you!
status-firefox-esr60: fixed → verified
Flags: needinfo?(daniel.bodea)
Comment on attachment 8987837 [details]
Bug 1465458 - Fix launching downloads without a file extension on Windows.

We're not going to be shipping a 52.9 dot release.
Attachment #8987837 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52-
status-firefox-esr52: affected → wontfix
tracking-firefox-esr52: ? → -
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.