firefox - the associated helper application does not exist

Bug #239952 reported by Savvas Radevic on 2008-06-14
326
This bug affects 62 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
epiphany-browser (Ubuntu)
Undecided
Unassigned
Declined for Jaunty by Chris Coulson
Declined for Lucid by Chris Coulson
Maverick
Undecided
Unassigned
firefox (Ubuntu)
Medium
Chris Coulson
Declined for Jaunty by Chris Coulson
Declined for Lucid by Chris Coulson
Maverick
Medium
Chris Coulson
firefox-3.0 (Ubuntu)
Low
Unassigned
Declined for Jaunty by Chris Coulson
Declined for Lucid by Chris Coulson
Maverick
Low
Unassigned
firefox-3.5 (Ubuntu)
Undecided
Unassigned
Declined for Jaunty by Chris Coulson
Declined for Lucid by Chris Coulson
Maverick
Undecided
Unassigned

Bug Description

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) wrote :

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.

Changed in firefox-3.0:
importance: Undecided → Low
status: New → Confirmed
Hew (hew) wrote :

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.

Changed in firefox-3.0:
status: Confirmed → Triaged
Hew (hew) wrote :

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

Hew (hew) on 2008-07-12
description: updated
Savvas Radevic (medigeek) wrote :

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?

description: updated
Savvas Radevic (medigeek) wrote :

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

description: updated
TJ (tj) on 2008-09-08
Changed in xulrunner-1.9:
assignee: nobody → intuitivenipple
importance: Undecided → Medium
status: New → Confirmed
TJ (tj) wrote :

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

TJ (tj) wrote :

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) wrote :

Much obliged :)

TJ (tj) wrote :

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) wrote :
Download full text (3.3 KiB)

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

Read more...

TJ (tj) wrote :

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) wrote :

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) wrote :

this should be fixed in final release.

Changed in xulrunner-1.9:
milestone: none → ubuntu-8.10
Alexander Sack (asac) wrote :

not an ephy issue.

Changed in epiphany-browser:
status: New → Invalid

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

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

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

TJ (tj) wrote :

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>

TJ (tj) on 2008-09-17
Changed in ubuntuforums.org:
status: New → Confirmed
Changed in xulrunner-1.9:
status: Confirmed → In Progress

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.

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

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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

Changed in firefox:
status: Unknown → Confirmed

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) wrote :

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

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

Connor Imes (ckimes) on 2008-12-20
Changed in ubuntuforums.org:
status: Confirmed → Invalid
TJ (tj) on 2008-12-20
Changed in ubuntuforums.org:
status: Invalid → Confirmed
Steve Stalcup (vorian) on 2008-12-21
Changed in ubuntuforums.org:
status: Confirmed → Invalid
status: Invalid → Confirmed
TJ (tj) on 2009-02-13
Changed in xulrunner-1.9:
assignee: intuitivenipple → nobody
status: In Progress → Confirmed
Hew (hew) on 2009-03-25
Changed in firefox-3.0 (Ubuntu):
status: Triaged → Incomplete
Changed in xulrunner-1.9 (Ubuntu):
status: Confirmed → Incomplete
milestone: ubuntu-8.10 → none
description: updated
Hew (hew) on 2009-03-26
Changed in xulrunner-1.9 (Ubuntu):
status: Incomplete → Triaged
Changed in firefox-3.0 (Ubuntu):
status: Incomplete → Invalid
44 comments hidden view all 124 comments
David Clayton (dcstar) wrote :

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) wrote :

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) wrote :

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

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) wrote :

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

affects: xulrunner-1.9 (Ubuntu) → firefox (Ubuntu)

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

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) wrote :

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) wrote :

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

GrandVizier (grandvizier) wrote :

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) wrote :

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

Alexander Amelkin (spirit-rc) wrote :

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

tags: added: patch
Nigel Babu (nigelbabu) wrote :

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.

tags: added: patch-forwarded-upstream
removed: patch
TheCat (chris-shaffer) wrote :

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

Jeremy Davis (jedmeister) wrote :

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) wrote :

"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) wrote :

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

Changed in firefox-3.5 (Ubuntu):
status: New → Invalid

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.

Mikael Strom (mikael-sesamiq) wrote :

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) wrote :

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

Changed in firefox (Ubuntu Maverick):
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → ubuntu-10.10
Changed in firefox:
importance: Unknown → Medium
Changed in firefox (Ubuntu Maverick):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in firefox (Ubuntu Maverick):
status: Fix Committed → Fix Released
.cobnet (mattias-campe) wrote :

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) wrote :

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) wrote :

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

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

Ric Flomag (ricflomag) wrote :

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) wrote :

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) wrote :

Thanks Chris, the issue is solved in TB.

Chris Coulson (chrisccoulson) wrote :

Excellent, that's great news. Thanks for testing

raketenman (sesselastronaut) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in firefox-3.0 (Ubuntu):
status: Invalid → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in firefox-3.5 (Ubuntu):
status: Invalid → Fix Released

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

ARULARASU (arularasug) on 2012-02-28
Changed in ubuntuforums.org:
assignee: nobody → ARULARASU (arularasug)
ARULARASU (arularasug) on 2012-02-28
Changed in ubuntuforums.org:
status: Confirmed → Fix Committed
Changed in ubuntuforums.org:
status: Fix Committed → Confirmed
assignee: ARULARASU (arularasug) → nobody
no longer affects: ubuntuforums.org

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

Changed in firefox:
status: Confirmed → Fix Released
Displaying first 40 and last 40 comments. View all 124 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.