Linux: User defined helper applications not honored by browser.

VERIFIED WORKSFORME

Status

Core Graveyard
File Handling
--
major
VERIFIED WORKSFORME
17 years ago
2 years ago

People

(Reporter: etymxris, Assigned: Bill Law)

Tracking

Trunk
Future
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Build 20010831.

1. Set up helper application with following values:

Set mimetype: audio/x-mpegurl
Set suffix: m3u
Set application: xmms %s
  OR
Set application: /usr/bin/xmms
  OR
Set application: /usr/bin/xmms %s
2. Restart browser.
3. Go to mp3.com and try to stream any mp3 (it will be an *.m3u file).
4. You get a pop-up asking you where to save file.
Actual Results: Mozilla handles like any other unknown mime-type, asking you to
save file.

Expected Results: Mozilla launches xmms with m3u file.

This behavior occurs whether or not the "Ask me before saving" flag is checked.

The UI appears to work. The changes made through the UI appear to persist, and
show up in the mimeTypes.rdf file. The only discrepancy is that I enter the
extension as m3u, and it always shows up (even in mimeTyes.rdf) as M3U.

This may be a duplicate of one of the numerous other Helper application bugs,
but I am submitting as a separate bug until we figure out which one it is.
Does it work if you run Mozilla as root ?
(Reporter)

Comment 2

17 years ago
I'm already running everything as root. I can run xmms just fine by itself.
Streaming works fine through netscape 4.x when I set up the helper application
there.

Comment 3

17 years ago
WFM with a current CVS build, Linux.

I added /usr/bin/xmms (and not the additional %)
Was promted to use helper app or save to disk.

I remember that modifying helper types horked up my mimeTypes.rdf on an earlyer
occation.
Reporter: Can you attach that file in this bugreport
You find the file in ./mozilla/Default/<salt>/

Comment 4

17 years ago
ahh i misunderstood this bug.
Seems unchecking the box for "Ask before.." isn't at all honored.
There are more bugs on this: bug 86531, bug 98115
Full path to helper app has no effect. It will launch once i confirm it in the
prompting popup, but i have uncheced "Ask  before" so it should have launched
xmms without further delay.
(Reporter)

Comment 5

17 years ago
Created attachment 48119 [details]
mimeTypes.rdf on affected machine
(Reporter)

Comment 6

17 years ago
No, the problem is that it simply doesn't work at all. No matter what I do, it
seems, I never get mozilla to launch xmms. It simply won't launch it. I'm never
prompted to use the helper type. The only option I ever get is to save to disk.
Mozilla always handles the file as if it doesn't even recognize the mime type at
all.

Perhaps it is that mozilla automatically capitalizes the extension "m3u" to
"M3U" when saving. But all files at mp3.com end in lower case "m3u". If mozilla
is case sensitive, it would not recognize the type at all.

To test this, I tried putting one of mp3.com's *.m3u files as a *.M3U file on my
own web server, but I cannot properly test this case since I don't know how to
set the server side mime types correctly. It simply loads the text of the file
into the browser when I click on the file in this instance.

Also, I am using the latest available download, which is 20010831, not a self
build from the latest CVS source.

Will try again with another mime type.
(Reporter)

Comment 7

17 years ago
pdf has the exact same results:

Set mimetype: application/pdf
Set suffix: pdf
Set application: /usr/bin/xpdf

Comment 8

17 years ago
there's so much there... i only got this when i added the helper app:

 <RDF:Description about="urn:mimetype:externalApplication:audio/x-mpegurl"
                   NC:path="/usr/bin/xmms"
                   NC:prettyName="xmms" />
  <RDF:Description about="urn:mimetypes">
    <NC:MIME-types resource="urn:mimetypes:root"/>
  </RDF:Description>

Comment 9

17 years ago
reopened bug 48948 is related.
Reporter, could you please try a clean profile and report the results?  That
mimeTypes.rdf looks like it's gone through a few mozilla releases that used
slightly different mimeTypes.rdf formats....

Comment 11

16 years ago
I am seeing the same problem on OpenVMS. We use the "helper app" interface to
define and invoke a PDF viewer when a page type of "application/pdf" is
encountered. This used to work on OpenVMS, but now its not (not sure when it
stopped working).

I just blew away my mimetypes.rdf and re-added the helper app. Made no
difference.  Something is definitely broken here. Marking bug confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 12

16 years ago
Created attachment 55541 [details]
Here's my newly created mimetypes.rdf

Comment 13

16 years ago
I should add that OpenVMS builds like a UNIX variant.

Comment 14

16 years ago
I just tried this on M0.9.3 and it didn't work there, so this has been broken
for a while.

I also tried on my M0.9.6 (tip) build from the end of last week, and that failed
too - so it hasn't been fixed yet!

Comment 15

16 years ago
I stepped through this with the debugger to see if I could figure out what was 
going on. Well, from the mime type it managed to figure out the right helper 
app, and it access()'d that to make sure it existed. Everything was moving along 
real nice and then I hit this:

// this code is incomplete and just here to get things started..

In LXR this line at:
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperApp
Service.cpp#289

Is this why it doesn't work? Has this part of the code been rewritten but never 
completed?

cc'ing mscott since his name is all over these changes, especially interesting 
is the change 1.72 in June with a comment "New Helper App design".

Comment 16

16 years ago
mscott
Assignee: neeti → mscott

Comment 17

16 years ago
I am experiencing this bug as well (0.9.5 2001101202 on linux here).  It doesn't
even properly exec the application i specify for the mime type (only tested with
m3u audio/x-mpegurl).

So... I ran mozilla under strace.  I saw the following (written from memory, not
pasted; sorry)

 execve("/sbin", ["/sbin", "/home/greg/tmp/3Thgjkd.m3u"], [74 entries]) = EPERM
 (or was it EINVAL?)

Regardless of what the actual error was, that's silly.  why was it trying to
execute "/sbin" instead of the configured application /usr/bin/xmms?

Something strange is afoot at the circle K.

Comment 18

16 years ago
Anyone who works on this bug, see my postings to bug 115819. I'm sure this is 
the same problem, and I have some debug/trace info there.

Comment 19

16 years ago
Not sure if this is related, but I'm using Red Hat Linux 7.2 and the
mozilla-0.9.7-0 rpm. Despite setting up an overriding entry for application/pdf,
the default xpdf application is always run. This would imply that the
mimeTypes.rdf file is just plain getting ignored.

HTH
People who are having these issues should try a recent build (post-0.9.8).  I've
landed several patches lately to address problems with helper apps from prefs
not being picked up (mostly case-sensitivity stuff).

And then there's the problem Colin is describing which is an issue on Unix if
you run as root.

Comment 21

16 years ago
-> file handler
Assignee: mscott → law
Component: Networking → File Handling
QA Contact: benc → sairuh
(Assignee)

Comment 22

16 years ago
->Future

If we get feedback on Boris comment, and bug reports indicate that there's 
something more than the problem described in bug 115819, then we can move it up.
Target Milestone: --- → Future

Comment 23

16 years ago
Annoying bug. It also exists on a Sparc Solaris 8 / mozilla 1.0rc1.

I got it working with these steps:
mv ~/.mozilla ~/.mozilla.old
Under "Helper Applications" add the mime thing you want
click on the appropriate link and choose "Open using ..."
NEVER touch the "always ask before opening..." thing.

Took me a while to figure this out. Looks kinda simple now doesn't it?

Comment 24

16 years ago
I have experienced this bug on RC 2 on linux. I run as root.
Here is my scenario: I try clicking on an audio/x-scpls link
for an mp3 stream. The link goes to a server which does a redirect
to a listen.pls file on shoutcast. The save as dialog always pops up.
http://www.bluemars.org/ is the url.
No matter what I set for the helper app, this doesn't cause the 
helper app to work.
Dru,

I think your problem is Bug 95828 (Running Mozilla as root prevents helper apps
from launching). It affects me also. Unfortunately that bug seems to be
inactive. Please put your comments there. Or vote for that bug.

Comment 26

16 years ago
Confirming on 1.0 RC 2, Mac OS 9.2.x. The behavior is as described in the first
entry. Also noted that Moz converts upper-case extensions to all lower-case
extensions for this platform also, and that clicking a link to a user-defined
MIME type results in the browser displaying the file. 

Change platform affected to ALL?
Please keep this bug linux-only... especially since as far as I know this should
now be fixed on Linux (this bug is worksforme, and I have yet to hear a Linux
person say otherwise).

Please file a separate bug on MacOS, cc me, and provide the urls at which you
are seeing the bug as well as the contents of your mimeTypes.rdf file (as an
attachment).

Comment 28

16 years ago
Created attachment 84377 [details]
Mozilla mime types file

Comment 29

16 years ago
    Still broken for me as of build-id 2002052020.
    The site is "http://www.buffyupn.com/video/bufa/bufapicker.html"; I have
entries that should cover both Quicktime and Windows Media (see attachment).  
     Boris - should I file a separate bug for FreeBSD, or is it better to mark
this as a multiple OS issue?
Robert, that site only seems to have <object>s/<embed>s... we don't handle those
with helper apps at all (bug 116027).
QA Contact: sairuh → petersen

Comment 31

15 years ago
*** Bug 179245 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
This should be fixed in a recent build that includes the fix for Bug 86640.
Reporter - can you try to reproduce this with a current build?
Depends on: 86640
Marking worksforme due to lack of responses and inability to reproduce... If
anyone is still seeing this (not with <object>, mind you), please reopen and
provide the steps to reproduce...
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 34

15 years ago
I've also ran into this problem, because I used to put a %s on the line, which
doesn't work. Now I've found out, that it's impossible to put any options to a
helper application. Thinking about xmms, it would be nice to put a "xmms -e" in
the helper application line, but unfortunately it doesn't work.
(Reporter)

Comment 35

15 years ago
This works for me now as well. I can also just click on the link before any MIME
type has been setup, point to the application, and have it work.

Setup:
mimetype: audio/m-mpegurl
suffix: m3u
application: /usr/bin/xmms

If the issue is that templates such as "/usr/bin/xmms -e %s" are not honored,
then that should be a different bug. This is just that NO helper applications
were being honored.
Status: RESOLVED → CLOSED
Please don't use "closed"
Status: CLOSED → REOPENED
Resolution: WORKSFORME → ---
-> wfm
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
(Reporter)

Comment 39

15 years ago
I am the original reporter. Why should I not be able to close it?
Because "closed" should not be used in the Product "browser/Mailnews"
Verified is the right state for a bug.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.