User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.1) Gecko/2008091700 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.1) Gecko/2008091700 Firefox/3.0.1 When a download has an unrecognised mime-type the extension is used to determine what handlers to list in the HelperApp dialog. The user makes a choice. When the download completes the user choice is ignored and the mime-type is used to determine the handler, and when one isn't found, the browser displays the error dialog "Download Error" that says: "/tmp/(filename) could not be opened, because the associated helper application does not exist. Change the association in your preferences." Reproducible: Always Steps to Reproduce: 1. Attempt to download a file with an unrecognised mime-type but recognised extension 2. Choose the handler Actual Results: Download error occurs Expected Results: Chosen handler opens the downloaded file. This bug was originally reported in Ubuntu Launchpad bug #239952 https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/239952

commit d14a61e1d07dcc0c8015114b13609104b0688502 Author: TJ <linux@tjworld.net> Date: Wed Sep 17 01:29:10 2008 +0100 When an incorrect or unrecognised Content-Type is found, and GetFromType() fails, GetFromExtension() is used to get the mime-type from the extension. When the download completes the helper fails to launch since it is re-evaluated using the (unrecognised) mime-type but no fall-back on the extension is done. This fix makes another call to GetFromType() after GetFromExtension() to determine the helper application and configure the mimeInfo object correctly (closes LP #239952 and Mozilla bug # 455626). Signed-off-by: TJ <linux@tjworld.net> diff --git a/mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp b/mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp index 39c4cb9..8300a61 100644 --- a/mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp +++ b/mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp

FWIW, it passes my current test suite (which is not as complete as I would like it to be yet), except for 1 subtest that relies on the current behaviour, which may or may not be the right thing. This behaviour is that currently, when you do getFromTypeAndExtension('wrong/type', 'knownextension'), you get a handler with a type of 'wrong/type', and 'knownextension' as the sole extension in the extensions list. The handler also doesn't equals() the handler you would get from getFromTypeAndExtension('correct/type', 'knownextension'); With your patch applied, this behaviour changes, and both handlers are similar. Boris, do you think this is a good thing ? I actually don't know what the windows or mac builds do in this case. I'll try to get the test case running on windows to see... Also, while your patch is nice for a possible 1.9.0 fix, I think it's not the right thing to do on trunk, because it ends up duplicating work. GetFromExtension is already doing a lot that GetFromType does, which you end up doing twice, then. That part is addressed in my patch for bug #444440.

(Boris, I got a question for you in comment #2)

Note this patch might solve my problem with getFromTypeAndExtension(null, 'knownextension') with my patch (not tested, though)

> I actually don't know what the > windows or mac builds do in this case. I'll try to get the test case running on > windows to see... I'd do that if I could get a hand on xpcshell.exe... Neither standard nor Tinderbox builds include it, and I don't have the tools to build ffx myself :-/

getFromTypeAndExtention('someType', 'someExtension') guarantees a return value that has type 'someType'. It probably shouldn't return any extensions other than 'someExtension' and the known extensions for 'someType'. We seriously need a regression suite for this code; it's pretty fragile, and UI consumers depend on the details to get behavior right in a number of corner cases, including some security bugs... Ideally we could find someone to go through all the old bugs on this and write tests. As for building, how are you testing your other patches to this code? Any build with --enable-tests should have xpcshell, I would think.

Oh, you mean building it on Windows... Let me see what I can dig up.

(In reply to comment #6) > getFromTypeAndExtention('someType', 'someExtension') guarantees a return value > that has type 'someType'. It probably shouldn't return any extensions other > than 'someExtension' and the known extensions for 'someType'. But what is supposed to happen when 'someType' is something that doesn't exist ? > We seriously need a regression suite for this code; it's pretty fragile, and UI > consumers depend on the details to get behavior right in a number of corner > cases, including some security bugs... Ideally we could find someone to go > through all the old bugs on this and write tests. I'm trying to write an exhaustive test, though I can only write tests for the unix port. I think a third of the tests I'm currently writing could be made to work on the other ports, but the rest is going to be tricky. This is also why I'd like to be able to do some testing on Windows at least. I must say it would be useful to have xpcshell shipped in tinderbox builds and the test suite been made easily runnable with these builds (i.e. without having really built or configured the build)

(In reply to comment #8) > I'm trying to write an exhaustive test, though I can only write tests for the > unix port. I think a third of the tests I'm currently writing could be made to > work on the other ports, but the rest is going to be tricky. This is also why > I'd like to be able to do some testing on Windows at least. I must say it would > be useful to have xpcshell shipped in tinderbox builds and the test suite been > made easily runnable with these builds (i.e. without having really built or > configured the build) If you can write the XPCShell tests, I can run them on Windows as well for you. And yes, it would be useful to be able to do testing without requiring a debug build, we are working on that in bug 433228. I thought there was also a bug addressing xpcshell too, I may need to file it :/

> But what is supposed to happen when 'someType' is something that doesn't exist You mean a type we know nothing about? Return a MIME info with that type, and our best guess at the extensions for it. Since we know nothing about those, the only thing we can put in there is 'someExtension'. For what it's worth, I started a tryserver build that should hopefully have xpcshell packaged; I'll report on the outcome once it's built. There's also been discussion about shipping test packages in addition to the existing tinderbox packages, I think. I guess my point was that a series of tests based on past bugs that are now fixed might be a better way to ensure coverage of those particular issues than just a single exhaustive test based on reverse-engineering the current code. That is, we want both: an exhaustive test, and individual regression tests.

http://mavra.perilith.com/~luser/ffxpcshell.zip should have an xpcshell in it.

(In reply to comment #11) > http://mavra.perilith.com/~luser/ffxpcshell.zip should have an xpcshell in it. Thanks, I'll give it a try tomorrow.

(In reply to comment #10) > > But what is supposed to happen when 'someType' is something that doesn't exist > > You mean a type we know nothing about? Return a MIME info with that type, and > our best guess at the extensions for it. Since we know nothing about those, > the only thing we can put in there is 'someExtension'. Interestingly, that's not what the windows port does. The windows port returns the set of extensions for the type it guesses from the 'someExtension' i.e getFromTypeAndExtention('wrong/type', 'eps') has ['eps', 'ps', 'ai'] as extensions. Anyways, actually most of the test suite I already wrote worked almost unmodified but I'll try to have a better (faked) controlled environment to have all environments return the same (faked) values (we can't really depend on a specific OS configuration, right ?) Would you mind doing another tryserver build with xpcshell, but for mac, this time ? PS: Maybe all this should go in yet another bug, titled 'enhance helper service xpcshell test suite'.

FYI, the above difference (and maybe the extensions order disparity i reported earlier) is due to the addition of extraMimeEntries to the mimeInfo.

> Interestingly, that's not what the windows port does. The Windows port has no concept of returning information for a MIME type. It just maps the type to an extension and returns the info for that extension, always. Which means that in this case its just returning its info for 'eps'. Not much we can do about that given how Windows does file types, but I don't think we want that behavior on Linux. I haven't figured out yet how to tweak the Mac build system to package xpcshell, and I don't have a libxul build on hand (needed to package), but I've put up an optimized Mac xpcshell for a build from yesterday or so at <http://web.mit.edu/bzbarsky/www/xpcshell>. With any luck it'll do what you want.

(In reply to comment #15) > > Interestingly, that's not what the windows port does. > > The Windows port has no concept of returning information for a MIME type. It > just maps the type to an extension and returns the info for that extension, > always. Which means that in this case its just returning its info for 'eps'. But nsExternalHelperService adds info from extraMimeEntries, which means some mime types have extra extensions information, even in that case where the type was wrong. (The more I look at the exthandler code, the less it makes sense as a whole...) > Not much we can do about that given how Windows does file types, but I don't > think we want that behavior on Linux. > > I haven't figured out yet how to tweak the Mac build system to package > xpcshell, and I don't have a libxul build on hand (needed to package), but I've > put up an optimized Mac xpcshell for a build from yesterday or so at > <http://web.mit.edu/bzbarsky/www/xpcshell>. With any luck it'll do what you > want. Thanks. I'll give it a try tonight.

> But nsExternalHelperService adds info from extraMimeEntries Might be worth double-checking why. > The more I look at the exthandler code, the less it makes sense as a whole... It's working around a number of OS and web server bugs, which doesn't help....

(In reply to comment #15) > I haven't figured out yet how to tweak the Mac build system to package > xpcshell, and I don't have a libxul build on hand (needed to package), but I've > put up an optimized Mac xpcshell for a build from yesterday or so at > <http://web.mit.edu/bzbarsky/www/xpcshell>. With any luck it'll do what you > want. Would you have a version that doesn't depend on the CHUD framework ?

Not offhand; all my builds are --enable-shark. :( I'll see what I can dig up, if installing CHUD is a non-starter on your end. Worst case I'll just need to clobber and build from scratch without --enable-shark.

> I'll see what I can dig up, if installing CHUD is a non-starter on your end. Unfortunately, the Mac is not mine, so that's definitely a non-starter :(

https://build.mozilla.org/tryserver-builds/2008-09-17_08:55-bzbarsky@mozilla.com-PackageXPCShell-Take2/bzbarsky@mozilla.com-PackageXPCShell-Take2-firefox-try-mac.dmg should do the trick, I think.

It worked, thanks, and I must say the Mac version seems completely broken compared to the 2 other ones :( mimeSvc.getFromTypeAndExtension('application/postscript', 'ps') gives a handler with extensions list ['eps'] mimeSvc.getFromTypeAndExtension('application/postscript', null) gives a handler with extensions list ['eps'] mimeSvc.getFromTypeAndExtension('application/postscript', 'eps') gives a handler with extensions list ['eps'] mimeSvc.getFromTypeAndExtension('application/postscript', 'ai') gives a handler with extensions list ['ai', 'ps', 'eps']; mimeSvc.getFromTypeAndExtension('application/postscript', 'foo') gives a handler with extensions list ['ps', 'eps', 'ai']; The only good point is that it's consistent with getPrimaryExtension: mimeSvc.getPrimaryExtension('application/postscript', null) is 'eps'; mimeSvc.getPrimaryExtension('application/postscript', 'eps') is 'eps'; mimeSvc.getPrimaryExtension('application/postscript', 'ps') is 'eps'; mimeSvc.getPrimaryExtension('application/postscript', 'ai') is 'ai'; mimeSvc.getPrimaryExtension('application/postscript', 'foo') is 'ps';

(interestingly, xpcshell wants a window server connection when running the testcase, but not when run alone)

Yeah, the mac MIME type code stopped being seriously maintained just about when I got involved with the project. It's been awhile. ;)

It doesn't help any that the MIME lookup stuff went from type/creator to extension-based in moving from OS Classic to OS X, and no one really updated the logic to deal well.

This is an old bug. But I just encountered it in FF 3.6, 32 bit linux build on centos 5.4.

Still getting it in Ubuntu as well fwiw. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100308 Ubuntu/10.04 (lucid) Firefox/3.6

Hello guys, I'm using Fedora 12 and had this bug opening RAR, ZIP, etc files from firefox. I solved it by choosing (usr/bin/file roller) instead of Archive Manager as default. Does this make sense?

This seems to be fixed in a recent trunk build for me: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100428 Ubuntu/10.04 (lucid) Minefield/3.7a5pre

(In reply to comment #28) > Hello guys, > > I'm using Fedora 12 and had this bug opening RAR, ZIP, etc files from firefox. > I solved it by choosing (usr/bin/file roller) instead of Archive Manager as > default. > > Does this make sense? That is a workaround. (In reply to comment #29) > This seems to be fixed in a recent trunk build for me: > Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100428 > Ubuntu/10.04 (lucid) Minefield/3.7a5pre It happens on some systems with certain mime types provided by web server. It may happen with some files, and may not happen with some other files, even if the file ext are same. See also Bug 464443.

Hello all, anyone can reproduce this error FFv3.6.8 by this step: 0) Run your PC or virtual machine from Ubuntu 10.04 32 or 64 bit LIVE CD or Installed version. 1) Login into http://ubuntuforums.org 2) Try download this file from this post: http://ubuntuforums.org/showpost.php?p=8707510&postcount=6 3) You can see the same error as I, http://pokazywarka.pl/bug576854/#zdjecie425983 . In FF, I have not get TXT entry in Edit > Preferences > Application.

Just to inform you, with firefox 4 beta this error vanished.

Bug 327323 might be the fix, at lease it fixed Bug 464443.

This remains a huge issue for me as of Nov 9/2010, a couple of years after is was reported. My system will not open any .DOC despite the fact that I have associates this extension variously with Word 2003 and Open Office Writer. I am now running Win 7 Pro. The error message is also unclear and unhelpful...."the associated helper application does not exist". What I'd like to suggest is adding what the system thinks the associated helper application is? That would help me find a workaround. At the moment I do not know what or where's it's looking. This should be raised from Normal to Urgent level. For those encountering this issue in Firefox and Thunderbird, it almost forces us to use different software and dump Mozilla.

Sid, if you open Preferences, go to the "Applications" pane, and type "doc" in the search field, what do you see?

Thanks for the fast response. In Thunderbird, there is no Applications pane (that's in Firefox) but there is an Attachments pane, which is where I set it for Microsoft Word (which fails). I have also tried other programs that I do have loaded, and which work in other situations, like Open Office Writer -- everything fails. This is how I set the associations I referred to in my original report. As I said, nothing works. One possibility is that, if I used the currert version of MS Word, it might actually work. The fact that I crippled the new Word (for which I have lo license because I like the older versions better) may be at the root of my specific problem.

Sid, I suggest trying support.mozilla.org.... It doesn't sound like your problem is this bug (which is mostly a linux/mac issue, since they do their helper app mappings by MIME type)...

This bug was also fixed indirectly by the landing of bug 327323

Indeed, this is fixed with later versions of firefox. Thank you!