Closed Bug 373621 Opened 18 years ago Closed 8 years ago

File upload set mime type as application/download instead of application/pdf

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 50
Tracking Flags:
Tracking Status
firefox50 --- fixed

People

(Reporter: gissurj, Assigned: xidorn)

References

Details

Attachments

(2 files)

convert
25.50 KB, application/pdf
Details
Bug 373621 - Make mime-type of PDF not overridable.
58 bytes, text/x-review-board-request
bzbarsky
: review+
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 Using our two Groupware (CLE) web applications (BSCW and Sakai), mime type encodings for PDF is set to application/download instead of e.g. application/pdf (only PDFs has been tested). Icons seems wrong as a result and (in BSCW) renaming files can lead to loss of file type due to removal of extension. Link to screenshot of upload dialogue (in Sakai) https://ecampus.ruc.dk/access/content/group/people.gissurj.testbed/Bugzilla%20report%20link/Firefox002.png Link to uploaded document (of Mime-type application/download): https://ecampus.ruc.dk/access/content/group/people.gissurj.testbed/Bugzilla%20report%20link/A-1-Alpha-Ward.pdf If you are interested in reproducing the error, please try to register for a free public account ... - at BSCW (Frauenhofer): http://bscw.fit.fraunhofer.de/pub/bscw.cgi?op=rmail - at Sakai (Unicons TestDrive-version): https://www.academusopencampus.com/registration/register/pilot_checkout1.php Reproducible: Always Steps to Reproduce: 1. choose add (document) in CLE 2. let browser decide Mime-type 3. check Mime-type on uploaded document Actual Results: Mime-type set to application/download Expected Results: Mime-type should have been application/pdf
This is also happening to me, but in a slightly different manner. I have a html form that allows file uploads and is processed with a PHP script. When ever I try to upload a PDF file from Firefox 2.0.0.3 on Windows the mime type that is detected is always listed as application/x-pilot instead of application/pdf When I tested under Brand X (aka IE) it always showed application/pdf.
Are these all dupes of each other? Or perhaps related to another meta-bug? Bug 373621 – File upload set mime type as application/download instead of application/pdf (edit) Bug 323462 – Sent pdf file is damaged, if sent in IE it is fine using yahoo mail (edit) Bug 336212 – Firefox won't upload pdf files from academic medical journal websites. IE will upload pdf immediately (edit) Bug 326821 – Mimetype output wrong on upload via php($_FILES -file_type) with FF 1.5.0.1 (edit)
I am usimg firefox 2.0.0.8 on Linux. The simple example here shows that when it uploads a PDF file, it gives it an application/x-download content-type instead of application/pdf. Both following HTML and CGI are on http://www.math.technion.ac.il/~rl/ for you to verify that: ==> upload.cgi <== #!/bin/sh echo 'Content-Type: text/plain' echo exec 2>&1 set -x grep -aim1 content-type ==> upload.html <== <form enctype="multipart/form-data" action="upload.cgi" method="POST"> <input name="file" type="file" /> <input type="submit" /> </form> Browse http://www.math.technion.ac.il/~rl/upload.html using opera or even lynx, enter a PDF name and submit, you'll get the output + grep -aim1 content-type Content-Type: application/pdf However, doing the same with firefox you get + grep -aim1 content-type Content-Type: application/x-download This fails many system which upload PDF files, e.g. PHP publishing systems. It seems to me all the bugs described are identical.
I suspect this should be wanted-firefox3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
OS: Mac OS X → All
Hardware: Macintosh → All
I investigated this a little further. Moving mimeTypes.rdf solved the problem. I am almost sure that the problem comes from the following lines which I had inside: <RDF:Description RDF:about="urn:mimetype:application/x-download" NC:value="application/x-download" NC:editable="true" NC:fileExtensions="pdf" NC:description="Portable Document Format"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-download"/> </RDF:Description> I also had <RDF:Description RDF:about="urn:mimetype:application/pdf" NC:fileExtensions="pdf" NC:description="Portable Document Format" NC:value="application/pdf" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/pdf"/> </RDF:Description> Later in the file, but perhaps the first took precedence. As I said I moved the file away, but I can still experiment with it. Anyway, Firefox uses now my ~/.mime.types and ~/.mailcap, and a new mimeTypes.rdf was created which is virtually empty.
This is similar problem to Bug 387258(force save of text/plain due to RDF entry created by HTTP header by server). To Zvi Har'El: Do you remember the site who returned "application/x-download" for file extension of ".pdf"?
Adding 323462, 336212, 326821 in "Blocks:" for ease of track.
Blocks: 323462, 326821, 336212
CC-ing to Boris(owner of Bug 387258). What is solution for this ".pdf" & multiple mimeTypes.rdf entries & upload mime-type case? I think possible solutions of this case are; (a) asking user for which, (b) never use mimeTypes.rdf entry when upload, (c) higher priority of system defined mime-type when upload
The solution is to fix the issues described in bug 332690.
Depends on: 332690
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: file.handling → file-handling
I am experiencing this bug as well. In Firefox 2.0.0.9, PDF mime types are displaying as application/force-download, as mentioned above. However, what I find interesting is that in Flock 1.0.1, which is essentially Firefox 2.0.0.9 with a different skin and some alternate features, the mime type that the browser selects is correct.
Marc, you clearly just have different preferences set in the two browsers. I'm not sure Firefox exposes the UI you'd need to change the Firefox preference in question, though.
I don't think this is a bug. IMHO, duplicating the purpose of mimeTypes.rdf would be a bad idea and could yield inconsistent behavior. The real problem is that the mimeTypes.rdf file contains incorrect data (the effect can also be seen when downloading files: Firefox displays incorrect information about the type of a file). I've submitted bug 649321 about the automatic modification of mimeTypes.rdf (and more generally the Applications Preferences, because FF4 no longer has a mimeTypes.rdf file, but the modification problem is still visible).
I cannot comment whether this is a bug... but #487976, one of the many bugs that have been marked as a dupe of this bug, *is* definitely a bug. I suspect (but have not confirmed) that many of the others marked as dupes are also real bugs. The statement "The real problem is that the mimeTypes.rdf file contains incorrect data" is incorrect, at least for bug #487976. That is not the problem, and cannot be the problem. mimeTypes.rdf provides a mapping from NAME to MIME TYPE. That is a great last resort, but if the actual type of the file as reported by the OS should take precedence. Names are simply that: names; they may or may not have anything to do with the type of the file.
OK, but there's the same problem with download (when the MIME type provided by the server is unknown): Firefox currently uses the filename extension and mimeTypes.rdf (or equivalent for FF4) instead of another method. At least under Linux, if a change is done for the upload (e.g. by looking at the file contents), then the same change should be done for the download, to be consistent.
Attached file convert —
jh
In Firefox 13.0.1 the MIME of pdf is known as application/x-download
(Additional info) In Firefox 13.0.1 the MIME of pdf is known as text/html on Mac
(In reply to edward66 from comment #35) > (Additional info) > In Firefox 13.0.1 the MIME of pdf is known as text/html on Mac I don't think this depends on the platform, but on what the user did in the past. IMHO, the cause of this problem is bug 649321: after some download, the mimeTypes.rdf file gets incorrect information (leading to what is described in Comment #5), and this incorrect information is reused for file upload.
(In reply to Vincent Lefevre from comment #36) > (In reply to edward66 from comment #35) > > (Additional info) > > In Firefox 13.0.1 the MIME of pdf is known as text/html on Mac > > I don't think this depends on the platform, but on what the user did in the > past. IMHO, the cause of this problem is bug 649321: after some download, > the mimeTypes.rdf file gets incorrect information (leading to what is > described in Comment #5), and this incorrect information is reused for file > upload. Thanks for your input and your theory is right. But as long as the "incorrect" information resides in the mimeTypes.rdf, the upload of pdf cannot be done. The chance of having a "correct" mimetypes.rdf that I can see is low in my case where the majority of workstations are reporting an application/x-download, application/octet-stream are being uploaded instead of application/pdf
I've also hit this bug now, which reports a PDF as text/html. This is caused by downloading a PDF file via a PHP script that sends first the text/html mimetype and then redirects to the PDF file. Useragent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Still see this issue *frequently* on Windows XP machines using even the latest Firefox 17 and 18.
Scenario reproduced here as well: My colleagues, a customer and I independently found out that an upload form for PDF files, which is handled by PHP on the server side and worked flawlessly for months, suddenly refused to accept PDF files in Firefox 20 (20.0.0 or 20.0.1) sometimes(!). The header of the uploaded files was "application/download" instead of "application/pdf" or "application/x-pdf". Testing with Internet Explorer as a first cause study, which worked fine (file header was "application/pdf"), made me think of a bug in Firefox 20 until I found this report. In order to do further investigation, I closed Firefox 20 and launched a portable version of Firefox 3.6 and did another test, which worked fine as well (header was "application/pdf"). Then, I opened Firefox 20 again, tested again, and suddenly, the upload worked fine again, because the file header said "application/x-pdf". I do not know if restarting Firefox 20 or what else fixed the problem, but will keep an eye on it.
I would assume this to become more of an issue now (6 years after the bug was initially opened) that more and more people will opt to download PDF files to circumvent pdfjs. And yes, it's still an issue with FF 21. Oh well, one more aggressive commit message referencing a Mozilla bug.
Let's just add insult to injury, FF21 does not report ONE COMPLETELY WRONG FILETYPE, noooooo that would be too simple, it reports AT LEAST TWO, based on some arcane rules totally opaque to the user! You have the choice of * application/download * application/x-download <about 200 words worth of expletives deleted for brevity.>
one more * application/force-download
I fixed this problem by resetting firefox: https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems It looks like the manner in which FF handled applications had changed. By resetting, application handling reverted to defaults and all is well.
This is what's occurring: 1.) Download a file with the .pdf extension and a MIME type incorrectly reported by the server as 'application/unknown'. 2.) Choose to open with Adobe Acrobat X and mark the box 'Do this automatically from now on'. 3.) An entry is added to the mimeTypes.rdf file <RDF:Description RDF:about="urn:mimetype:application/x-download" NC:value="application/x-download" NC:editable="true" NC:fileExtensions="pdf" NC:description="Portable Document Format"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-download"/> </RDF:Description> 4.) Attempt to upload any PDF file to any server. 5.) ‘application/x-download' is now being sent as the MIME type instead of ‘application/pdf’ 6.) The desired .rdf entry is: <RDF:Description RDF:about="urn:mimetype:application/pdf" NC:fileExtensions="pdf" NC:description="Portable Document Format" NC:value="application/pdf" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/pdf"/> </RDF:Description> 7.) Either delete the incorrect entry, or delete the MimeTypes.rdf file and let Firefox recreate this file on restart. "By default, many web servers are configured to report a MIME type of text/plain or application/octet-stream for unknown content types. As new content types are invented or added to web servers, web administrators may fail to add the new MIME types to their web server's configuration. This is a major source of problems for users of Gecko-based browsers, which respect the MIME types as reported by web servers and web applications." "Note: You may get problems if you download a file that is labeled with the wrong Internet media type. There is no way to identify or delete a bad entry in the list. If this happens you may need to look at the file mimeTypes.rdf in your Firefox profile folder. Deleting the mimeTypes.rdf will reset all download actions to the default settings." http://kb.mozillazine.org/MimeTypes.rdf https://developer.mozilla.org/en/docs/Properly_Configuring_Server_MIME_Types http://support.mozilla.org/en-US/kb/set-how-firefox-handles-different-file-types
I resolved my bug (https://bugzilla.mozilla.org/show_bug.cgi?id=953274) by deleting the Firefox configuration. Perhaps this could be the solution for this bug too.
No, deleting the configuration is just a bad workaround, not a solution. And the problem may reappear any time after doing that.
Hello guys, has there been any progress on this almost 7 years old bug? It's becoming a bit pain since File API provides the same incorrect MIME information which may eventually be used for validation purposes. We have encountered this while adding a client-side file validation for file uploads in Nette Framework, see here: https://github.com/nette/nette/commit/33fa7fd66c1282a1bcf69c4b21da30b439b2c104.
I've hit this problem now on the other side: users were complaining that PDF files uploaded to our site somehow did not get shown as pdf files afterwards. When uploading files we avoid "file type guessing", assuming/hoping that the user agent will be able to provide us with a more correct content-type in the upload request. From what I can see that works just fine with other major browsers we support, but with this issue in firefox I'm thinking of changing our _server-side_ code to detect the user-agent, and ignore content-type information provided in the request if the user-agent is any version of firefox, falling back to file type guessing based on the extension of the file. Do you see any other way here? With that said, I'm wondering how Firefox actually determines that the application/x-download entry is the correct one to use. I can see that "if you get to see a .pdf file reported as application/x-download by a server, then use the handler X" is a reasonable approach, but using those entries for *uploads* seems to be completely wrong: the source of the file is a local file system, not a misbehaving/misconfigured web server, so when sending content types to servers the entry should not apply IMVHO.
I have detected this problem in Firefox 28.0, but with KML files. Instead to report the mime type as application/vnd.google-earth.kml+xml, Firefox reports it as application/x-download.
I can confirm comment #45 https://bugzilla.mozilla.org/show_bug.cgi?id=373621#c45 for Firefox 30.0. My personal FF has PDF registered to application/force-download, application/octet, application/octetstream, application/x-download (these are only some). The first one is used by uploads in my case. It is a valid usecase to save these mime-Types for future download behaviour. But for uploads from the local system, the order in which the associated mime type is picked is flawed. This is not only a problem with PDF, but with many filetypes that combine mime-types and file extensions when downloaded. On one of the servers I have access to, these Mime-Types are sent for uploads from various users: application/x-download application/force-download application/x-msdownload application/octet-stream application/download "application/octet-stream" file/x-msdownload All of these should send correct mime-types.
(In reply to karoshi from comment #51) > It is a valid usecase to save these mime-Types for future download > behaviour. No, it isn't valid even for download, since mime types like application/octet-stream may cover various real file types. See bug 649321.
(In reply to Vincent Lefevre from comment #52) > No, it isn't valid even for download, since mime types like > application/octet-stream may cover various real file types. See bug 649321. True, I assumed that file extension and mime type are combined for future reference. Your referenced bug proofed me wrong, what makes this issue even more troubling.
I think a bug, like this, that now requires me to write browser-specific code on both front-end and back-end with comments like "Firefox broken" should be either "major" or "critical", not "normal". Especially as the code I'm going to write is to stop validating mime-type, and just hope the uploaded file is a real PDF. It is an especially frustrating bug, because of the way it comes and goes. So tech support won't be able to reproduce it, and will tell customers it is their problem. Or tell them to use another browser. (In my case the exact same PDF files I kept on my desktop for testing with were being uploaded as application/pdf yesterday and are application/download today! Chrome still uploads them as application/pdf, which was the point I got suspicious.)
(In reply to Darren Cook from comment #54) > It is an especially frustrating bug, because of the way it comes and goes. > So tech support won't be able to reproduce it, and will tell customers it is > their problem. Or tell them to use another browser. > > (In my case the exact same PDF files I kept on my desktop for testing with > were being uploaded as application/pdf yesterday and are > application/download today! Chrome still uploads them as application/pdf, > which was the point I got suspicious.) The same problem happens to me in my firefox installation. The very same PDF which were uploaded fine some days ago can't be uploaded now as file is identified as 'application/download'. Other firefox installations or browsers however, identify the file as application/pdf and files get uploaded ok.
As stated in comment #5 in 2007, "why this bug occurs" is clear since early stage of this bug. So no need of more "me too". - Firefox silently generates bad entry in mimeTypes.rdf, when bad mime-type is passed from someone. - Firefox always uses the bad entry in mimeTypes.rdf upon file upload, once bad entry was generated in mimeTypes.rdf. This behavior(and bad UI design and inadequate back-end implementation around it) was ported to Tb and Sm. Because many mailers(especially poorly implemented Web mail application) pretty easily produces bad mime-type, "problem by this bug" was far severe in Thunderbird/SeaMonkey. "Web mail via Browser" is very popular nowadays, so "cause of this bug in Firefox" is never "bad mime-type in a Web site" only. As stated in comment #9, developer's decision on this bug is next : The solution is to fix the issues described in bug 332690. Recovery action is already well known, as stated in comment #46 and in many many Thunderbird bugs: Delete mimeTypes.rdf file, then restart Firefox. Note : In Thunderbird, this bug is critical for many users because this bug can occur upon any mail send with file attachment. So, for ease of "deletion of mimeTypes.rdf entry", "Action=Delete this entry" was added to Action column of panel which is corresponds to Firefox's Tools/Option/Applications.
Note that a malicious/mischievous/clueless user can essentially bomb a Thunderbird installation from the outside by sending a poorly-configured file. This clearly shows that this is a serious exploit and not simply a minor nuisance that occasionally requires blanking all your settings.
Ok, so hold on, this bug seems to occur in Firefox 37.0 and has been open since before the latest "financial" crisis / Lehman brothers prang? I really think it's time to fix. My "mimeTypes.rdf" RDF:Description RDF:about="urn:mimetype:application/x-download" NC:fileExtensions="pdf" NC:description="PDF document" NC:value="application/x-download" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-download"/>
Yes, fix this bug would be really great !!
I experience this issue on a daily basis across a wide variety of Windows Operating Systems and Firefox versions. We are being forced over to using Chrome because our users are not adept enough to delete mimetypes.rdf every day so they can upload PDFs to our online filing system. It's a shame, but Chrome always works when uploading PDFs. This issue was reported back in 2007. Why hasn't mozilla addressed it? Not important enough?
Getting your **** together would be really great. This is a bug from 2007 people, 8 years and counting. Are you kidding me?
There seems to have been a change in Google Drive earlier this month that is revealing this problem on numerous users' systems. There have been a few reports on SuMo and several active threads on the Google Drive forum. Is there any way to privilege the OS-level association of PDF with application/pdf over other content types added to mimeTypes.rdf interactively when identifying the content type for upload purposes?
Would it be okay to move pdf => application/pdf from the "extra" mime types (line 571 of nsExternalHelperAppService.cpp) to the list of hard-coded mime types (lines 510-534) so that it will supersede mimeTypes.rdf? One reason for reluctance would be if .pdf were used by other applications (issue arose with .css per https://bugzilla.mozilla.org/show_bug.cgi?id=332690#c3). According to http://filext.com/file-extension/PDF there have been some other uses over the years, but it's difficult to assess their significance relative to the problems encountered by typical users.
It is possible for a plugin or an extension go override MIMR type update behavior? Possibly we can just go around Mozilla's broken scheme? This has been a PITA for years now.
Guys, I can't believe that this bug still exists in the most recent Firefox, almost 10 years (!!!) after first reported. This is a very serious bug. Recently I noticed that for every PDF I upload to Google Drive (on my Linux machine using firefox), later I cannot view it (on any of my devices) - even though the file is calls "something.pdf", both Google Drive and my phone claim they don't know how to display it. I would have assumed this was a Google bug, if it weren't for an old PDF I uploaded a couple of years ago - and still works perfectly to this day! On a whim, I went and checked this bug report, and sure enough, my ~/.mozilla/firefox/.../mimeTypes.rdf had the lines: <RDF:Description RDF:about="urn:mimetype:application/x-download" NC:fileExtensions="pdf" NC:description="Portable Document Format" NC:value="application/x-download" NC:editable="true"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-download"/> </RDF:Description> When I outright deleted the whole mimeTypes.rdf file (what is it good for, anyway?), everything went back to normal! Now I can upload new PDF files to Google Drive, and Google recognizes them properly as PDFs, and so does my phone when I download the file back. PLEASE, let's not ignore this bug for another 10 years. It's time to fix it.
By the way, if you appreciate irony, note that Zvi Har'El, who analyzed this bug 9 years ago (see above), is my father. He unfortunately died 8 years ago, and today I ran into the same bug. My daughter already reached the age that she started to use Firefox too, so soon she'll probably run into this bug too, and this will have become a 3-generation bug...
Product: Core → Firefox
nyh, thanks for sharing that very human element. I'm sorry the bug hasn't made it up the priority list as yet.
Hi Dan, Is this assigned to anyone? It seems as if it's not a problem on Win 10 FF47 but running into this on Win 7 FF47. Kind regards, Philip O.
Not currently; there's an "Assigned To" field at the top of the bug that tracks that, and since it's currently set to "nobody", it's free for the taking by interested developers.
We have just switched to Chrome as our default browser. Since Mozilla doesn't think this is a problem, we just won't use their product. Their product is free so they don't really have to care about the end user experience. As proven with this 10 year old bug.
Anna, agreed but such a shame! I told our client to switch to Chrome as well.
Let's borrow the logic from bug 641102 comment 2. Firefox has builtin PDF support via PDF.js, so let's not bother the system, and just force the mime-type of PDF to be application/pdf?
Comment on attachment 8775534 [details] Bug 373621 - Make mime-type of PDF not overridable. https://reviewboard.mozilla.org/r/67714/#review64830 I guess.... I really wish someone would actually pick up ownership of this junk and fix bug 332690 instead of having to play whack-a-mole. :( But the front end team seems to think the front end writing garbage to mimeTypes.rdf is not their problem somehow. :(
Attachment #8775534 - Flags: review?(bzbarsky) → review+
Note that a bunch of bugs got marked as duplicates of this one that are NOT fixed by this patch, because they were not about the "pdf" extension. Someone should probably go through and reopen those...
Decade seems not to be enough for Mozilla to fix such a nasty bug, sad... I actually think this should be considered as a security issue since the browser trusts an arbitrary web server and merely accepts & reuses provided information. Attacker could easily forge user's mime type for any future file uploads and web servers would receive such malicious type... This is ridiculous: <RDF:Description RDF:about="urn:mimetype:image/svg" NC:value="image/svg" NC:editable="true" NC:fileExtensions="php" NC:description="PHP script"> <NC:handlerProp RDF:resource="urn:mimetype:handler:image/svg"/> </RDF:Description>
Yes, that is what bug 332690 is about.
The problem is more general than ajaxSketch and SVG files (or perhaps bug 332690 is just poorly titled).
Keywords: checkin-needed
It seems this issue appears for pdf more frequently than others, so let's fix it first (and reopen the non-pdf duplicates).
Why not simply dispose of the mimetypes.rdf file and everything that goes along with it, and replace it with hooks into the native OS filetype support? There is, evidently, otherwise no value in supporting the feature at all.
Assignee: nobody → xidorn+moz
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c2211a92bce2 Make mime-type of PDF not overridable. r=bz
Keywords: checkin-needed
Charles, we have hooks into the OS filetype support and fall back to those if there is nothing overriding them. The mimetypes file allows thing like a Firefox user selecting a different app than the OS-default for the given filetype and having that information be saved. It also used to allow (not sure whether it still does) explicitly adding extension to type and type to helper app mappings via the Firefox preferences. Arguably, we should skip looking in mimeTypes.rdf when doing the extension-to-type mapping, maybe. Especially if there is no longer UI for adding such mappings directly.
https://hg.mozilla.org/mozilla-central/rev/c2211a92bce2
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox50: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
This bug is now marked as fixed for Firefox 50, but what about Thunderbird? Bug 487976 in Thunderbird had been resolved as a duplicate of this bug because it was in Core at that time. But what's the status now?
Isn't the REAL issue here that the type gets changed (either accidentally or maliciously) through no action on the end user's part and without the user's knowledge? Shouldn't that NEVER happen?
Arguably, yes. The user is choosing to associate the type to an action (helper app, or saving to disk), and the UI saves all the information it has: extension, type, description, etc. This creates an association from extension to type. Again, that's what bug 332690 is supposed to be about.
Change History of this bug. > By cbook@mozilla.com > status-firefox50 : fixed > Status : RESOLVED > Resolution : FIXED > Target Milestone : Firefox 50 > Last Resolved : 2016-07-29 10:27:19 I thought this bug was for "upload issue caused by wrong mime-type in mimeTypes.rdf which was generated by careless UI" what will perhaps be resolved by some solutions(which may be provided in bug 332690). Major reasons of that this bug was kept open and many bugs were duped to this bug, were; - bug 332690 is still for "ajaxSketch breaks handling of local SVG files" only, as known by the bug summary, even though developers correctly understand problem/cause/possible solutions in bug 332690. - bug 332690 is not for "upload issue". Biggest problem in "upload issue" is; Even if first creator of bad mime-type at server(or of web mail attachment) is other software, once this bug occurs, Firefox will continuously create bad mime-type at server or in web mail attachment, and, as Virus does do, Firefox will continuously distribute bad mime-type to other Firefox/Thunderbird/SeaMonkey. Is this bug for "extention=.pdf" case only? If so, all duped bugs for non-pdf case have to be re-opened. And, if so, any file extension, for which same problem as this bug was reported at B.M.O, is better registered in nsExternalHelperAppService.cpp as done for file-extension=.pdf by this bug, unless non file-extension-specific-solution will be provided shortly.
Please note that "RESOLVED/FIXED of this bug because a patch for this bug has been landed" means "all duped bugs to this bug are also resolved and any problem of the duped bugs are also fixed by the patch proposed in this bug". If not, what is meaning of "DUPLICATES:" in B.M.O?
WADA, all of that was already covered in the patch review....
(In reply to Boris Zbarsky [:bz] (Vacation until Aug 21) from comment #78) > Note that a bunch of bugs got marked as duplicates of this one that are NOT > fixed by this patch, because they were not about the "pdf" extension. > Someone should probably go through and reopen those... I've reopened bug 306471 and duped some of the others there. Let's see if we can find a more generic solution in that bug or in bug 332690. I also reopened bug 441791 because it's not at all clear how some of this will/won't impact thunderbird.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: