ZIP file MIME type is not recognized
Categories
(Firefox :: File Handling, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | fixed |
People
(Reporter: Tundra4991, Assigned: Gijs)
References
(Blocks 1 open bug)
Details
Attachments
(5 files)
Screenshot
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
In essence if I select a ZIP file into an input tag and then try to read the file using javascript, it's MIME type is empty.
This problem can be reproduced online.
STEP 1) Open this link with Firefox (or anywhere, where you can run a HTML page on a web browser with javascript) -> https://www.w3schools.com/js/tryit.asp?filename=tryjs_myfirst
STEP 2) Insert this code:
<!DOCTYPE html>
<html>
<body>
<h2>Check file type</h2>
<input type="file" multiple onchange="showType(this)">
</body>
</html>
<script>
function showType(fileInput) {
var files = fileInput.files;
for (var i = 0; i < files.length; i++) {
var name = files[i].name;
var type = files[i].type;
alert("Filename: " + name + "\nFile Type: " + type);
}
}
</script>
STEP 3) click on RUN >> (or open the HTML file with the firefox web browser)
STEP 4) Click on the browse button and select any ZIP file
An alert popup should show up with the information of the file - it's filename and filetype.
Actual results:
If i select a ZIP file, then it's File Type (MIME type) is not recognized:
Filename: httpd-2.4.25-win64-VC14.zip
File Type:
If I select any other file such as .ico or .exe or .png, then the file type is recognized just fine:
Filename: favicon.ico
File Type: image/x-icon
Expected results:
The ZIP file type should be recognized:
Filename: httpd-2.4.25-win64-VC14.zip
File Type: application/zip
Note: I tested this on 2 different computers with Firefox, TOR browser and Waterfox - all yield the same results. On Brave browser (chromium engine) this works just fine.
|
||
Comment 1•5 years ago
|
||
Cannot reproduce. How did you check that the file on your machine with the ending .zip has the correct MIME type set?
|
Reporter | |
Comment 2•5 years ago
|
||
Strange that it works on your side but not on the 2 systems, that I have.
Are you testing it on a Linux system or on a Windows system?
Since I am on Windows I cannot use the "file" command to determine it's MIME type. I uploaded my ZIP file on https://www.htmlstrip.com/mime-file-type-checker and I see the MIME type is application/zip
This basically happens on several ZIP files and not only that one I have.
I can potentially download your ZIP file and retest it on my end to determine the problem further.
|
||
Comment 3•5 years ago
|
||
We should probably include APPLICATION_ZIP in extraMimeEntries: https://searchfox.org/mozilla-central/rev/4415bec7a49c50a338167d9c8934527b9cae59d0/uriloader/exthandler/nsExternalHelperAppService.cpp#481. Otherwise you won't get any MIME type info on systems missing an association for .zip.
|
Assignee | |
Comment 4•5 years ago
|
||
This would be trivial except bug 1609466 added a test whose assumptions will now change.
|
|
Assignee | |
Comment 5•5 years ago
|
||
|
|
Assignee | |
Comment 6•5 years ago
•
|
||
(In reply to Tom Schuster [:evilpie] from comment #3)
We should probably include APPLICATION_ZIP in
extraMimeEntries: https://searchfox.org/mozilla-central/rev/4415bec7a49c50a338167d9c8934527b9cae59d0/uriloader/exthandler/nsExternalHelperAppService.cpp#481. Otherwise you won't get any MIME type info on systems missing an association for.zip.
This is a good guess, but my copy of Windows thinks zip files are application/x-zip-compressed and that works fine. And in fact, we have unit tests that check that this is the case. I checked release, a blank nightly profile, and used mozregression to fire up 78 nightly to match the ESR version from comment #0, and all of them list a mimetype when using the testcase from comment #0 as described by the reporter.
Reporter: on your Windows machine, in the registry, if you check HKEY_CLASSES_ROOT\.zip, and the Content Type key in the right-hand pane, what does that say?
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
|
Reporter | |
Comment 8•5 years ago
|
||
|
|
Reporter | |
Comment 9•5 years ago
|
||
I checked on both of my Windows machines (both running Windows 10) and neither of them have this value under this registry key.
|
|
||
Comment 10•5 years ago
|
||
Interesting. I tried installing WinRAR in a clean Windows 10 VM and the "Content Type" key kept the value "application/x-zip-compressed".
|
|
Assignee | |
Comment 11•5 years ago
|
||
(In reply to Tundra4991 from comment #9)
I checked on both of my Windows machines (both running Windows 10) and neither of them have this value under this registry key.
Wow. I asked folks internal to Mozilla, and every single respondent (I heard from 10 different people) has this registry key.
Have you ever run some kind of "clean up" software on your machines in the past, or perhaps installed and then uninstalled an archiver program?
We can go ahead with the patch I was in the process of writing as a "just in case" kind of fix, and it may help other situations, but I'm curious why this key is missing for you, and if anything else is missing, too. I'm also skeptical that this patch would make it to 78esr (which you appear to be using?) for stability reasons, and so I'm trying to work out if there are other, better options to pursue here.
|
|
Reporter | |
Comment 12•5 years ago
|
||
I just played around with the Registry a bit. If this Register string entry is present, then on Firefox it will read whatever value it has. However if this string entry does not exist, then unlike on Firefox it does not stop Chrome (I use Brave, not Google Chrome) from detecting it's MIME type.
Anyway I used Glary Utilities to optimize my personal workstation and on my other machine I do not even have Glary Utilities installed. I did not uninstall WinRAR or any other archiving software. The most I did was install PeaZip along with WinRAR (WinRAR got there first).
May I try that modded Firefox version before it's official release so I can confirm whether the bugfix works on my ends? After that I would like to opt back for stable releases.
|
|
Assignee | |
Comment 13•5 years ago
|
||
(In reply to Tundra4991 from comment #12)
May I try that modded Firefox version before it's official release so I can confirm whether the bugfix works on my ends? After that I would like to opt back for stable releases.
Sure:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UZPHwbyxS5STQzXChShZLQ/runs/0/artifacts/public/build/target.zip (32-bit)
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ckdUL_rLT06IouQ8KRxSpw/runs/0/artifacts/public/build/target.zip (64-bit)
(these are based off of our current development branch, so they'll have additional changes and will run against a different FIrefox profile by default to avoid breaking your existing profile - I would not recommend overriding that selection as you may not be able to run your usual, 78esr-using, profile with esr again)
|
|
Reporter | |
Comment 14•5 years ago
|
||
Thanks!
I tested your bugfix on both of my machines with the provided links and now the ZIP MIME type is correctly recognized. Well done!
Is there any ETA when this bugfix will be published to the production Firefox version (major update, hotfix patch, whatever)?
|
|
Reporter | |
Comment 15•5 years ago
|
||
|
||
Comment 16•5 years ago
|
||
|
|
Assignee | |
Comment 17•5 years ago
|
||
(In reply to Tundra4991 from comment #14)
Thanks!
I tested your bugfix on both of my machines with the provided links and now the ZIP MIME type is correctly recognized. Well done!
Is there any ETA when this bugfix will be published to the production Firefox version (major update, hotfix patch, whatever)?
I've just queued it for landing. Assuming that goes well, it'll be in nightly builds (https://nightly.mozilla.org/) either tonight or tomorrow morning, and would become part of the 86 release, with which it'd reach beta on January 25, and release on February 23 (see https://wiki.mozilla.org/Release_Management/Calendar for our scheduling calendar). That's regular release though - if you're using ESR builds, I suspect we would not land the fix there due to the risk of regressions in enterprise applications, so it wouldn't be available until the next ESR branches, in July next year. For you personally, it might be easiest/quickest to just set the registry key we discussed to application/zip or application/x-zip-compressed, which would also address the issue.
|
|
Reporter | |
Comment 18•5 years ago
|
||
Well, the point is it's not just for me personally. We have clients, who will use our web application and we can't tell them all to put a registry tweak if they use a Windows system without that registry entry or to switch to Chrome. To (temporarily) solve this case of mine I have coded a workaround fix to check for file extension rather than MIME type (a not so good practice).
What we can instruct our clients however is to use an up to date web browser as soon as this fix goes public with the 86 release.
|
||
Comment 19•5 years ago
|
||
| bugherder | ||
Description
•