firefox - the associated helper application does not exist

[Savvas Radevic]

Clicking some links in firefox-3.0 to download files displays the open/save dialog correctly, but if 'open' is selected with the default application, it fails with an error. Saving works as intended.

The resulting error is:
Download Error
/tmp/(filename) could not be opened, because the associated helper application does not exist. Change the association in your preferences.

EXAMPLES:
http://ubuntuforums.org/showthread.php?p=5369513 (listed below):
Not working: File Type: odt test1.odt (7.3 KB, 0 views)
Not working: File Type: ods test2.ods (6.8 KB, 0 views)
Not working: File Type: txt test4 with space.txt (12 Bytes, 0 views)
Working: File Type: pdf test5.pdf (13.8 KB, 0 views)
Not working: File Type: py test6.py (15 Bytes, 0 views)
Not working: File Type: txt test3nospace.txt (9 Bytes, 0 views)
Not working: File Type: py test7withusrbin.py (41 Bytes, 0 views)

http://www.linuxforums.org/forum/ubuntu-help/60569-installing-wireless-client-wusb11v4-2.html (novo ficheiro.txt)
https://launchpad.net/ubuntu/+source/firefox-3.0 (Available diffs, affects all launchpad package pages)

WORKAROUND:
Save the file first, rather than using the firefox 'open' option.

All reported cases using:
Ubuntu Jaunty Jackalope 8.10 alpha 6 updated
Ubuntu Hardy Heron 8.04.1 (amd64 or i386)
firefox-3.0: 3.0+nobinonly-0ubuntu0.8.04.1

[Hew (hew)]

I can confirm the issue with this file. Saving the file and opening it manually avoids this problem. I have not encountered this problem anywhere else.

[Savvas Radevic (medigeek)]

Same with the attachments on this forum/topic:
http://www.linuxforums.org/forum/ubuntu-help/60569-installing-wireless-client-wusb11v4-2.html

[Hew (hew)]

http://www.linuxforums.org/forum/ubuntu-help/60569-installing-wireless-client-wusb11v4-2.html also displays the problem. Most text files are displayed in firefox, but when the save dialog is used for them, the bad association with Text Editor is apparent. Choosing the application /usr/bin/gedit manually in the open dialog works fine.

[Hew (hew)]

Also happens with "Available diffs" right here on launchpad. This shows the problem isn't specific to text files, and likely applies to all files.

eg. https://launchpad.net/ubuntu/+source/firefox-3.0

[Savvas Radevic (medigeek)]

Made a topic on ubuntuforums.org for testing: http://ubuntuforums.org/showthread.php?p=5369513
Let's hope they won't close it :)

All the attachments so far did not work, except .pdf - it opened the file correctly
Could be a problem related to desktop entries in /usr/share/applications/ ? Or firefox gives/badly parses a bad address to the applications?

[Savvas Radevic (medigeek)]

Added epiphany browser: http://ubuntuforums.org/showthread.php?t=857107#3
"Confirmed. Epiphany 2.22.2 - Hardy."

Happening on i386 too: http://ubuntuforums.org/showthread.php?t=857107#4
"The problem exists on my PC as well, running Ubuntu 8.04, Intel, 32-bits."

[TJ (tj)]

This is a problem caused by the interaction of xulrunner and Gnome VFS. Using the test files in Savvas' thread in the forums (http://ubuntuforums.org/showthread.php?p=5369513) a *successful* handling of the PDF file looks like this:

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
return NS_OK

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
return NS_OK

nsMIMEInfoBase::LaunchWithFile()
mPreferredAction=4
mPreferredAction==useSystemDefault
calling LaunchDefaultWithFile()

nsMIMEInfoUnix::LaunchDefaultWithFile()
nativePath=/tmp/test5-5.pdf
Using vfs
vfs->GetAppForMimeType()=1
app->Launch()

Whereas trying either of the text files (with or without spaces in names) gives this:

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
fallback to nsMIMEInfoImpl::GetHasDefaultHandler()

nsMIMEInfoBase::LaunchWithFile()
mPreferredAction=4
mPreferredAction==useSystemDefault
calling LaunchDefaultWithFile()

nsMIMEInfoUnix::LaunchDefaultWithFile()
nativePath=/tmp/test4 with space-4.txt
Using vfs
vfs->GetAppForMimeType()=1
mDefaultApplication=0
!mDefaultApplication NS_ERROR_FILE_NOT_FOUND

... and...

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
fallback to nsMIMEInfoImpl::GetHasDefaultHandler()

nsMIMEInfoBase::LaunchWithFile()
mPreferredAction=4
mPreferredAction==useSystemDefault
calling LaunchDefaultWithFile()

nsMIMEInfoUnix::LaunchDefaultWithFile()
nativePath=/tmp/test3nospace-1.txt
Using vfs
vfs->GetAppForMimeType()=1
mDefaultApplication=0
!mDefaultApplication NS_ERROR_FILE_NOT_FOUND

[Savvas Radevic (medigeek)]

Should we add gvfs package too then?

[TJ (tj)]

No. I'm working on isolating the problem. It is caused by an interaction but the issue is likely to be in xulrunner. I should have the solution and a fix later today.

[Savvas Radevic (medigeek)]

Much obliged :)

[TJ (tj)]

This is a combination of two 'bugs'. I'll address the first in this comment.

1. ubuntuforums.com web-server is misconfigured.

2. xulrunner correctly figuring out the mime-type from the file-extension but fails to set the variable that tells it which application to launch, therefore failing when it checks if mDefaultApplication is valid (not-null).

Web-server Content-Types response for attachments. For the following file attachments it reports the wrong mime-types. For text, the elements are reversed!:

.txt == text/plain
content-disposition: attachment; filename*=ISO-8859-1''test4%20with%20space.txt

Content-Type: plain/text

.odt == application/vnd.oasis.opendocument.text
content-disposition: attachment; filename*=ISO-8859-1''test1.odt

Content-Type: unknown/unknown

.ods == application/vnd.oasis.opendocument.spreadsheet
content-disposition: attachment; filename*=ISO-8859-1''test2.ods

Content-Type: unknown/unknown

.gz == application/x-gzip
content-disposition: attachment; filename*=ISO-8859-1''test4%20with%20space.txt.gz

Content-Type: unknown/unknown

PDF is correct though:

.pdf == "application/pdf
content-disposition: attachment; filename*=ISO-8859-1''test5.pdf

Content-Type: application/pdf

[TJ (tj)]

The second issue is that internal debugging shows xulrunner makes a second attempt to get the mime-type from gnome-vfs when the first (obviously based on the web-server Content-Type) fails. The second attempt appears to be based on the file's extension (I shall trace that aspect in my next debug session).

The problem is, having got the correct handler from gnome-vfs xulrunner seems to forget/lose it and not use it later when it actually wants to launch the handler.

Here's the report for a .gzip file. The web-server (ubuntuforums.org) mis-reports the Content-Type as:
content-disposition: attachment; filename*=ISO-8859-1''test4%20with%20space.txt.gz
Content-Type: unknown/unknown

----- log -----
nsGnomeVFSService::GetAppForMimeType("unknown/unknown", null)
calling gnome_vfs_mime_get_default_application()
Didn't get GnomeVFSMimeApplication

nsGnomeVFSService::GetAppForMimeType("application/x-gzip", null)
calling gnome_vfs_mime_get_default_application()
Successfully got GnomeVFSMimeApplication (id=file-roller.desktop, name=Archive Manager)
converting app to mozApp
transfering mozApp to aApp (0x425c380)

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
nsGnomeVFSService::GetAppForMimeType("unknown/unknown", null)
calling gnome_vfs_mime_get_default_application()
Didn't get GnomeVFSMimeApplication
fallback to nsMIMEInfoImpl::GetHasDefaultHandler()

nsMIMEInfoBase::LaunchWithFile()
mPreferredAction=4
mPreferredAction==useSystemDefault
calling LaunchDefaultWithFile()

nsMIMEInfoUnix::LaunchDefaultWithFile()
nativePath=/tmp/test4 with space.txt-2.gz
Using vfs

nsGnomeVFSService::GetAppForMimeType("unknown/unknown", null)
calling gnome_vfs_mime_get_default_application()
Didn't get GnomeVFSMimeApplication

vfs->GetAppForMimeType()=1
mDefaultApplication=0
!mDefaultApplication NS_ERROR_FILE_NOT_FOUND
----------

Here's a comparible log for a PDF file. The web-server Content-Type is:
.pdf == "application/pdf
content-disposition: attachment; filename*=ISO-8859-1''test5.pdf

----- log -----
nsGnomeVFSService::GetAppForMimeType("application/pdf", null)
calling gnome_vfs_mime_get_default_application()
Successfully got GnomeVFSMimeApplication (id=evince.desktop, name=Document Viewer)
converting app to mozApp
transfering mozApp to aApp (0x1140740)

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
nsGnomeVFSService::GetAppForMimeType("application/pdf", null)
calling gnome_vfs_mime_get_default_application()
Successfully got GnomeVFSMimeApplication (id=evince.desktop, name=Document Viewer)
converting app to mozApp
transfering mozApp to aApp (0x150bd60)
return NS_OK

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs

nsGnomeVFSService::GetAppForMimeType("application/pdf", null)
calling gnome_vfs_mime_get_default_application()
Successfully got GnomeVFSMimeApplication (id=evince.desktop, name=Document Viewer)
converting app to mozApp
transfering mozApp to aApp (0x2f9e920)
return NS_OK

nsMIMEInfoBase::LaunchWithFile()
mPreferredAction=4
mPreferredAction==useSystemDefault
calling LaunchDefaultWithFile()

nsMIMEInfoUnix::LaunchDefaultWithFile()
nativePath=/tmp/test5-7.pdf
Using vfs

nsGnomeVFSService::GetAppForMimeType("application/pdf", null)
calling gnome_vfs_mime_ge...

[TJ (tj)]

The explanation for the apparent forgetfulness of xulrunner is that there are two separate phases to the download process:

1. Populate the Helper Chooser Dialog list with mime-type helper applications
2. Launch with default mime-type helper

The solution would be to add functionality to nsMIMEInfoUnix::LaunchDefaultWithFile() that does the same thing as step 1 follows in determining the default helper.

However, Aexander has pointed me to a patch that may rework this process so the next step is to see if the patch has any positive effect on this default-handling in the absense of a sensible Content-Type from the web-server.

Here's the recent debug log showing the two phases.

=== log ===
*** POPULATE HELPER CHOOSER DIALOG ****

nsOSHelperAppService::GetMIMEInfoFromOS("unknown/unknown", "gz")

nsGNOMERegistry::GetFromType("unknown/unknown")
calling vfs->GetAppForMimeType()

nsGnomeVFSService::GetAppForMimeType("unknown/unknown", null)
calling gnome_vfs_mime_get_default_application()
Didn't get GnomeVFSMimeApplication

failed

!retval || !hasDefault

nsOSHelperAppService::GetFromExtension("gz")
calling LookUpTypeAndDescription()
LookUp failed
calling nsGNOMERegistry::GetFromExtension()

nsGnomeVFSService::GetMimeTypeFromExtension("gz", aMimeType)
calling gnome_vfs_mime_type_from_name()
aMimeType=application/x-gzip

nsGNOMERegistry::GetFromType("application/x-gzip")
calling vfs->GetAppForMimeType()

nsGnomeVFSService::GetAppForMimeType("application/x-gzip", null)
calling gnome_vfs_mime_get_default_application()
Successfully got GnomeVFSMimeApplication (id=file-roller.desktop, name=Archive Manager)
converting app to mozApp
transfering mozApp to aApp (0xf6abe0)

success

*** FILE DOWNLOAD COMPLETED ****

nsMIMEInfoUnix::GetHasDefaultHandler()
Using vfs
nsGnomeVFSService::GetAppForMimeType("unknown/unknown", null)
calling gnome_vfs_mime_get_default_application()
Didn't get GnomeVFSMimeApplication
fallback to nsMIMEInfoImpl::GetHasDefaultHandler()

**** ATTEMPT TO LAUNCH HELPER ***

nsMIMEInfoBase::LaunchWithFile()
mPreferredAction=4
mPreferredAction==useSystemDefault
calling LaunchDefaultWithFile()

nsMIMEInfoUnix::LaunchDefaultWithFile()
nativePath=/tmp/test4 with space.txt-4.gz
Using vfs

nsGnomeVFSService::GetAppForMimeType("unknown/unknown", null)
calling gnome_vfs_mime_get_default_application()
Didn't get GnomeVFSMimeApplication

vfs->GetAppForMimeType()=1
mDefaultApplication=0
!mDefaultApplication NS_ERROR_FILE_NOT_FOUND

[TJ (tj)]

Results of testing Mozilla bug #444440 patch (v3).

.txt file
Content-Type: plain/text

Helper chooser dialog suggests to open with "gedit.desktop". However, if "Other..." is selected from the list, and the file-browser dialog cancelled, Open With displays "Text Editor (default)".

If the "OK" button is pressed when "gedit-desktop" is displayed no error is reported but no helper is launched. If the "OK" button is pressed when "Text Editor (default)" is displayed, the "Download Error" dialog appears and reports that the helper application can't be launched - in other words, the same problem as reported by this bug originally.

.gz file
Content-Type: unknown/unknown

Helper choose dialig suggests to open "firefox 3.0.1". However, if "Other..." is selected from the list, and the file-browser dialog cancelled, Open with displays "Archive Manager (default)".

If the "OK" button is pressed when either "firefox 3.0.1" or "Archive Manager (default)" is displayed the "Download Error" dialog appears and reports that the helper application can't be launched.

.pdf
Content-Type: application/pdf

Helper chooser dialog suggests to open "Document Viewer (default)". Pressing the "OK" button launches the helper application (evince) as expected.

So, in summary, the mozilla patch doesn't solve the issue and, if anything, makes it more confusing.

[Alexander Sack (asac)]

this should be fixed in final release.

[Alexander Sack (asac)]

not an ephy issue.

[Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld)]

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

[Bugzilla-mozilla-tjworld (bugzilla-mozilla-tjworld)]

Created an attachment (id=338993)
Call GetFromType() after GetFromExtension() when mime-type is not recognised

commit d14a61e1d07dcc0c8015114b13609104b0688502
Author: TJ <email address hidden>
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 <email address hidden>

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

[Mh+mozilla (mh+mozilla)]

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.

[Mh+mozilla (mh+mozilla)]

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

[Mh+mozilla (mh+mozilla)]

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

[Mh+mozilla (mh+mozilla)]

> 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 :-/

[TJ (tj)]

commit d14a61e1d07dcc0c8015114b13609104b0688502
Author: TJ <email address hidden>
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 <email address hidden>

[Bzbarsky (bzbarsky)]

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.

[Bzbarsky (bzbarsky)]

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

[Mh+mozilla (mh+mozilla)]

(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)

[ctalbert (ctalbert)]

(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 :/

[Bzbarsky (bzbarsky)]

> 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.

[Bzbarsky (bzbarsky)]

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

[Mh+mozilla (mh+mozilla)]

(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.

[TJ (tj)]

xulrunner-1.9 packages to test this patch are now available in my PPA for Hardy and Intrepid.

Please report successes and any regressions.

https://launchpad.net/~intuitivenipple/+archive?field.name_filter=xulrunner-1.9&field.status_filter=published

[Hew (hew)]

Seems to present .diff.gz files (from https://edge.launchpad.net/ubuntu/+source/firefox-3.0 ) as text in the window now with 1.9.0.2+build3+nobinonly-0ubuntu2~ppa1i , which is great :-). I'll keep my eye out for any regressions.

[TJ (tj)]

Thanks Hew.

What happened to the same file beforehand?

Also, do you have Live HTTP Headers installed (http://livehttpheaders.mozdev.org/) ? If so, can you capture the HTTP *response* from the server that contains:

content-disposition:
Content-Type:

Forexample, for the page http://ubuntuforums.org/showpost.php?p=5755405&postcount=7 that will look like this:

HTTP/1.x 200 OK

Date: Wed, 17 Sep 2008 18:03:37 GMT

Server: Apache/2.0.55 (Ubuntu) PHP/5.1.2

X-Powered-By: PHP/5.1.2

Cache-Control: max-age=31536000, private

Vary: User-Agent

X-UA-Compatible: IE=7

Expires: Thu, 17 Sep 2009 18:03:37 GMT

Last-Modified: Tue, 09 Sep 2008 12:59:04 GMT

Etag: "84692"

Accept-Ranges: bytes

content-disposition: attachment; filename*=ISO-8859-1''test4%20with%20space.txt.gz

Content-Length: 53

Content-Type: unknown/unknown

X-Cache: MISS from feijoa.canonical.com

X-Cache-Lookup: MISS from feijoa.canonical.com:8800

Via: 1.0 feijoa.canonical.com:8800 (squid/2.6.STABLE18), 1.1 ubuntuforums.org

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Also, because everyone collects a set of personal handling preferences in the ~/.mozilla/firefox/${PROFILE}/mimeTypes.rdf which will affect how the attachment is dealt with, can you test the same file in a new clean profile (start Firefox from a command-line with "firefox -ProfileManager").

[Hew (hew)]

Before, a dialog would appear asking if I wanted to open or save the file. Saving worked fine, but opening resulted in the error mentioned in the description of this report.

Here is the (small) header from http://launchpadlibrarian.net/17537462/firefox-3.0_3.0.2%2Bbuild3%2Bnobinonly-0ubuntu1_3.0.2%2Bbuild3%2Bnobinonly-0ubuntu2.diff.gz :

HTTP/1.x 304 Not Modified
Date: Wed, 17 Sep 2008 15:22:10 GMT
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100

The behaviour is the same when using a fresh firefox profile.

[TJ (tj)]

Thanks Hew.

A side-note. That response header (304 Not Modified) shows the file is already in the browser's local cache so nothing is fetched - hence no Content-Type, etc.

During testing I have been clearing the browser cache using Edit > Preferences > Privacy

With "Ask me before clearing private data" selected press the "Clear Now..." button and deselect everything but "Cache" then press the "Clear Private Data Now" button.

[Mh+mozilla (mh+mozilla)]

(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'.

[Mh+mozilla (mh+mozilla)]

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

[Hew (hew)]

HTTP/1.x 200 OK

Date: Sat, 13 Sep 2008 15:52:23 GMT

Server: TwistedWeb/8.0.1

Content-Length: 3992

Content-Encoding: gzip

Last-Modified: Thu, 11 Sep 2008 15:36:09 GMT

Content-Type: text/plain

Age: 51094

X-Cache: HIT from arsenic.canonical.com

X-Cache-Lookup: HIT from arsenic.canonical.com:3128

Via: 1.0 arsenic.canonical.com:3128 (squid/2.6.STABLE18), 1.1 launchpadlibrarian.net

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

[Bzbarsky (bzbarsky)]

> 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.

[Mh+mozilla (mh+mozilla)]

(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.

[David Clayton (dcstar)]

And I get it using FF 3.6.3 on 10.04 beta at this - Ubuntu Forums - post:

http://ubuntuforums.org/showpost.php?p=9106627&postcount=2

[Runa (arundhati-bakshi)]

I am getting this on FF 3.5.9 on 9.04 on this forum:

https://xythos.lsu.edu/users/abaksh1/web/si.html

All of the PDFs open fine except the last one.

[David Clayton (dcstar)]

"I am getting this on FF 3.5.9 on 9.04 on this forum:

https://xythos.lsu.edu/users/abaksh1/web/si.html

All of the PDFs open fine except the last one."

Yep, same on my FF 3.6.3 10.04 - weird as the html looks ok and the other links work ok.

On my system I get the prompt to Open or Save the file for all of them, it is only after using "Open" that the error message for this file partially load in the Viewer, then the viewer exits with this error message.

I suspect that it is a problem with the Document Viewer/Firefox interface rather than FF itself - when the Viewer crashed/exits FF responds to that situation with the message we see.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

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

[Micah Gersten (micahg)]

Reassigning task to the firefox package as that's where the update will probably be first.

[Ginn-chen (ginn-chen)]

(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.

[Lazy (ubuntu-bugs-oittaa)]

This is still broken in Lucid when I try to open documents from internal Sharepoint server. If I download the document first and then click it from the download manager it works fine.

[.cobnet (mattias-campe)]

I can confirm wat Lazy is saying: this (very) annoying bug is still there with almost all the files that have application/force-download as file-type (see my earlier comment for more details).

[J (ouyang-jie)]

I also got this problem today. ubuntu 10.04. firefox 3.6.3

[GrandVizier (grandvizier)]

I have had this problem for ages. It is still there with Ubuntu Lucid & Firefox 3.6.3.
For instance with teh following pdf file:
http://tu-dresden.de/die_tu_dresden/fakultaeten/fakultaet_mathematik_und_naturwissenschaften/fachrichtung_mathematik/aims2010/dateien/Sessions-Lists.pdf

[Bernt (bernt-hullen)]

Yes here the same with Ubuntu Lucid and Firefox 3.6.3.
When does this bug be solved?

[Alexander Amelkin (spirit-rc)]

The bug is here for me too. Ubuntu Karmic + Firefox 3.5.9. It's EXTREMELY annoying!

[Nigel Babu (nigelbabu)]

This patch has been reviewed as part of operation cleansweep. Thanks for the patch and forwarding upstream, I'm marking the patch as patch-forwarded-upstream.

[TheCat (chris-shaffer)]

I am having the same problem with PDF files downloaded from YahooGroups, using Ubuntu 10.04 and Firefox 3.6.7.

[Jeremy Davis (jedmeister)]

I'm having this problem too (Ubuntu 10.04 / Firefox 3.6.8)

My suspicion is that it's caused by Firefox trying to save anything that you "open with' in the temp folder (as it does in Windows). In Ubuntu the user does not have write permissions to the temp folder (/tmp).

I thought this may be easy to fix but I have just scrolled through about:config and no mention of a temporary folder :(

[David Clayton (dcstar)]

"In Ubuntu the user does not have write permissions to the temp folder (/tmp)."

Rubbish, all users have access to write to /tmp, the system is specifically designed to allow this.

[Jeremy Davis (jedmeister)]

Thanks David. I stand corrected.

After getting the original error message when trying to "open with..." I was misguided by the error message that I receive when I double click on the failed file (in the Firefox Downloads window): "/tmp/filename could not be saved, because you cannot change the contents of that folder. Change the folder properties and try again, or try saving in a different location." (Incidentally the file is in /tmp and can be opened by the appropriate app by double clicking).

Rather than jumping to conclusions I should have double checked. As you say David, I can indeed write to /tmp Obviously I'm a Linux newb but there's not really any excuse for not double checking. Thanks for your patience :)

[SiB (przysowa)]

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.

[Nicolò Chieffo (yelo3)]

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

[Ginn-chen (ginn-chen)]

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

[Mikael Strom (mikael-sesamiq)]

I experience this frequently (like 50% of the times i try to open something on the net) with Firefox 3.6.8 and Ubuntu 10.04.

Extremely annoying! Is there a fix for this?

Thanks,
Mike

[SiB (przysowa)]

Mikael Strom: I agree with you.
In https://bugzilla.mozilla.org/show_bug.cgi?id=455626 you can read:

@Nicolò Chieffo: Just to inform you, with firefox 4 beta this error vanished.
@Ginn Chen: Bug 327323 might be the fix, at lease it fixed Bug 464443.

Then I thinking we must wait for official FF4 to resolve this case.
BR
Marcin (SiB) Przysowa

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 3.6.10+build1+nobinonly-0ubuntu3

---------------
firefox (3.6.10+build1+nobinonly-0ubuntu3) maverick; urgency=low

  * Fix LP: #239952 - the associated helper application does not exist.
    Where a launcher doesn't exist for a particular mimetype, use the file
    extension instead
    - add debian/patches/bz327323_att471859_lp239952_launch_from_extension.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Tue, 21 Sep 2010 23:09:29 +0100

[.cobnet (mattias-campe)]

I have firefox, version "3.6.10+build1+nobinonly-0ubuntu0.10.04.1" and in this package, the bug isn't fixed.

So I guess "3.6.10+build1+nobinonly-0ubuntu3" isn't the same package/version as "3.6.10+build1+nobinonly-0ubuntu0.10.04.1"?

[Chris Coulson (chrisccoulson)]

No, this is currently only fixed in Maverick. I'm trying to get the patch landed on this branch upstream, so that it will flow down to all supported Ubuntu releases.

[Chris Coulson (chrisccoulson)]

This change has landed upstream now, and will be in the next regular security update (3.6.11) on all Ubuntu releases

[Mark Shuttleworth (sabdfl)]

Out of curiosity, does the same issue affect t-bird?

[Ric Flomag (ricflomag)]

Indeed, this bug affects TB also:

/tmp/LettreCaravaneGroupeBilan6et7novembreOK-2.pdf could not be opened, because the associated helper application does not exist. Change the association in your preferences.

(thunderbird 3.1.4, Maverick)

[Chris Coulson (chrisccoulson)]

Please try the Thunderbird 3.1.5 RC build from the ubuntu-mozilla-security PPA (https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa). It has the same patch in.

[Ric Flomag (ricflomag)]

Thanks Chris, the issue is solved in TB.

[Chris Coulson (chrisccoulson)]

Excellent, that's great news. Thanks for testing

[raketenman (sesselastronaut)]

I'm experiencing this bug with firefox Version: 3.6.10+build1+nobinonly-0ubuntu0.10.04.1

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox-3.0 - 3.6.11+build3+nobinonly-0ubuntu0.8.04.1

---------------
firefox-3.0 (3.6.11+build3+nobinonly-0ubuntu0.8.04.1) hardy-security; urgency=low

  * New upstream release v3.6.11 (FIREFOX_3_6_11_BUILD3)
    - see USN-997-1
    - Fixes LP: #589236 and LP: #239952

  * Bump minimum system NSS to 3.12.8 after landing of (bmo: 600104) aka
    Bump minimum required version for system NSS to 3.12.8
    - update debian/rules
  * Bump minimum system NSPR to 4.8.6 after landing of (bmo: 567620) aka
    Bump minimum required version for system NSPR to 4.8.6
    - update debian/rules
  * Bump minimum version of sqlite to 3.7.1 after landing of (bmo: 583611) aka
    Upgrade to SQLite 3.7.1
    - update debian/rules
 -- Chris Coulson <email address hidden> Wed, 13 Oct 2010 13:13:11 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox-3.5 - 3.6.11+build3+nobinonly-0ubuntu0.9.10.1

---------------
firefox-3.5 (3.6.11+build3+nobinonly-0ubuntu0.9.10.1) karmic-security; urgency=low

  * New upstream release v3.6.11 (FIREFOX_3_6_11_BUILD3)
    - see USN-997-1
    - Fixes LP: #589236 and LP: #239952

  [ Jamie Strandboge <email address hidden> ]
  * AppArmor:
   - fix for Google Gears (LP: #644976)

  [ Chris Coulson <email address hidden> ]
  * Drop defer_syslibs_bumps_to_sru.patch - this was inherited
    from FF3.5, and is currently the only branch carrying this patch. The
    patch doesn't make much sense now we build with bundled libraries, and
    there is no guarantee now that those old library versions would be
    sufficient to do a build now anyway. In addition to that, we still
    check for the version of cairo required by upstream in debian/rules,
    despite this patch
    - remove debian/patches/defer_syslibs_bumps_to_sru.patch
    - update debian/patches/series
  * Bump minimum version of sqlite to 3.7.1 after landing of (bmo: 583611) aka
    Upgrade to SQLite 3.7.1
    - update debian/rules
  * Bump minimum system NSS to 3.12.8 after landing of (bmo: 600104) aka
    Bump minimum required version for system NSS to 3.12.8
    - update debian/rules
  * Bump minimum system NSPR to 4.8.6 after landing of (bmo: 567620) aka
    Bump minimum required version for system NSPR to 4.8.6
    - update debian/rules
 -- Chris Coulson <email address hidden> Wed, 13 Oct 2010 12:25:26 +0100

[Sid-sid-bursten (sid-sid-bursten)]

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.

[Bzbarsky (bzbarsky)]

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

[Sid-sid-bursten (sid-sid-bursten)]

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.

[Bzbarsky (bzbarsky)]

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)...

[Chris Coulson (chrisccoulson)]

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

[Savvas Radevic (medigeek)]

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