Last Comment Bug 83305 - Add correct parsing/spawning of handlers from mailcap entries
: Add correct parsing/spawning of handlers from mailcap entries
: helpwanted
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: x86 Linux
: -- normal with 13 votes (vote)
: ---
Assigned To: Joshua Kwan
: benc
: 186304 (view as bug list)
Depends on: 52441 78919 86640
Blocks: input-helper-apps 95091 115041 226138
  Show dependency treegraph
Reported: 2001-05-30 09:21 PDT by Boris Zbarsky [:bz]
Modified: 2015-12-16 09:19 PST (History)
19 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Boris Zbarsky [:bz] 2001-05-30 09:21:37 PDT
Once bug 78919 and bug 52441 are fixed, a parser for mailcap entry handlers 
should be added to nsOSHelperAppService::LaunchAppWithTempFile.  This will 
complete mailcap support for Mozilla.
Comment 1 Boris Zbarsky [:bz] 2001-05-30 09:34:07 PDT
Adding dependencies.

This should also remove the "dirty hack" introduced by bug 52441
Comment 2 Boris Zbarsky [:bz] 2002-01-03 21:23:06 PST
Not happening any time too soon... too much arch work to be done first.
Comment 3 Bram Cohen 2002-03-07 00:54:27 PST
I can't believe this bug is still in there. This means that mimetype handling is
broken, and is broken in a way which reminds the user that it's broken *every
time* they click on a link which uses a non-preconfigured helper app. This
seriously harms the UI of my application, which you can get here - - all I can tell people is that
the annoying dialogue you have to click 'yes' on every time is mozilla's fault,
and no, there's nothing you can do about it. 

As far as I can tell apps like xmms are acting as plug-ins rather than helper
apps, a non-cross-browser technique they most definitely should not have to do.
Comment 4 Boris Zbarsky [:bz] 2002-03-07 08:25:01 PST
If you note, this bug has a nonempty "depends on" field.  That field is not
there for fun.  Right now, there is simply no place to store the full mailcap
entry for later retrieval and parsing; arch work needs to be done for that. 
Since it seems I'm the only one who's interested in actually working on it
rather than whining about it, it won't happen till I have time, which will not
happen till I finish my thesis and graduate.

All that said, it is incredibly unlikely that what you're seeing is caused by
_this_ bug unless you depend on being able to execute arbitrary shell commands
in mailcap helper entries (rather than just running a program).  Does the dialog
that comes up get pre-filled with the helper app information correctly?  If so,
it sounds more likely that your users are just not checking the "never ask me
again" checkbox that dialog.
Comment 5 Bram Cohen 2002-03-07 08:49:38 PST
I just tried it with 0.9.8, and I'm seeing considerably better behavior -
previously unchecking the 'don't ask again' box didn't work, it kept re-asking
anyway (which, you're correct, doesn't appear to be _this_ bug, but I'm having
trouble following the maze of bugs related to mimetypes)

I consider asking that question even once to be broken behavior - it's already
configured, isn't it? That should be pretty clear. But I don't expect to be able
to make any headway arguing against that behavior because it isn't broken enough
to be something which might get fixed.

I also can't figure out if there's an RFE to have /etc/mailcap get re-parsed if
an unknown mimetype is encountered, to avoid having to restart mozilla in such
cases, but maybe that's hoping for too much...
Comment 6 Boris Zbarsky [:bz] 2002-03-07 08:56:13 PST
> I consider asking that question even once to be broken behavior - it's already
> configured, isn't it?

It is.  Unfortunately, the default configuration is often crap.  For example, on
RedHat Linux up through 7.2 the default "helper" for postscript is lpr.  They
didn't change it to gv till I filed a bug on them to do it, which was about 3
months ago.  So we give the user a chance to stamp their approval on the default
config or select something else to use.

> I also can't figure out if there's an RFE to have /etc/mailcap get re-parsed

There is not, but then again it's currently reparsed any time a type is unknown.
 We used to cache the result once we found a match, but the cache had major
issues and has been turned off (that may have been post-0.9.8).  It will not be
turned on again without addressing the problem you mention.
Comment 7 basic 2002-03-21 10:53:51 PST
remove self
Comment 8 Boris Zbarsky [:bz] 2002-04-16 10:24:59 PDT
The changes to enable "useSystemDefault" that are being made in bug 86640 will
make this possible even if bug 78919 is fixed.
Comment 9 Boris Zbarsky [:bz] 2002-08-31 01:01:52 PDT
not happening in the foreseeable future
Comment 10 Göran Uddeborg 2002-09-04 14:09:05 PDT
Am I mistaken if I conclude this is a security issue?  Say one, as could be the
default, has an /etc/mailcap entry

   application/postscript ; gv -safer %s

Then with the current partial implementation the effect would be to use gv, but
without the -safer flag, right?
Comment 11 Boris Zbarsky [:bz] 2002-09-04 18:29:57 PDT
That's correct, and a really good point... There may well be other apps which
have a "default" mode and a "secure" mode and we could be launching the less
secure mode...
Comment 12 Boris Zbarsky [:bz] 2002-12-20 12:45:58 PST
*** Bug 186304 has been marked as a duplicate of this bug. ***
Comment 13 benc 2003-01-08 09:32:15 PST
Uh, that bug is a security bug. Can we open it if it is indeed a dupe?
Comment 14 Boris Zbarsky [:bz] 2003-01-08 10:31:07 PST
I said it should be opened in that bug a few weeks back... but in typical
fashion that didn't help any.
Comment 15 Samir Gehani 2003-04-25 16:48:27 PDT
adt: nsbeta1-
Comment 16 Joshua Kwan 2005-06-30 11:23:34 PDT
Has this bug stagnated? I don't see why it's so hard to do it - I can try to
provide a patch if desired...

This is a really critical thing to get fixed, IMO.
Comment 17 Mats Larsson 2005-07-01 01:53:59 PDT
(In reply to comment #16)
> Has this bug stagnated? I don't see why it's so hard to do it - I can try to
> provide a patch if desired...
> This is a really critical thing to get fixed, IMO.

Agree. Great if you can fix it.
Comment 18 Boris Zbarsky [:bz] 2005-07-01 22:15:48 PDT
This stagnated because I'm frankly not interested in doing this at this point...
 If you post a patch, I'd be happy to review and help it land; let me know if
you need pointers to the code in Mozilla that handles mailcap files.
Comment 19 Marc Gariepy 2010-10-21 10:53:58 PDT
nice to see that in 2010, with firefox 4.0 this is still an issue
I work on LTSP on linux, we run gnome on the server and firefox on a thin client and to be able to integrate correctly firefox and the gnome desktop, i can add some entry in /etc/mailcap to be able to launch the applications on the server, here is on of mailcap entry that works with chromium but doesn't in firefox.
Do you think this bug will be solved soon ?  of shall i just wait another 10 year to see if the status will change to "OPEN"?

== mailcap entry ==
application/; /usr/bin/ltsp-remoteapps soffice -no-oosplash -calc '%s'; edit=/usr/bin/ltsp-remoteapps soffice -no-oosplash -calc '%s'; test=test -n "$DISPLAY"; description="Microsoft Excel Document"; nametemplate=%s.xls
Comment 20 Boris Zbarsky [:bz] 2010-10-21 11:27:49 PDT
Mark, see comment 18?
Comment 21 Patrick McManus [:mcmanus] PTO until Sep 6 2015-12-16 09:19:07 PST
would reopen with a plan and patch

Note You need to log in before you can comment on or make changes to this bug.