95091 - %s in helper application (or lack of)

Status: RESOLVED DUPLICATE of bug 57420

(Firefox :: File Handling, defect)

Description

[Austin Donnelly]

Mozilla 0.9.3 (BuildID 2001080104).  Linux ix86.

Once the bugs related to proper mailcap support are resolved, it would be
nice to automatically guess whether the temporary file argument needs to
be appended.  For example a handler of "foo %s" should not have the temp
filename appended, but should have the %s replaced by it.  A handler of
just "foo" should have the temp filename appended to it:

if (substring(helper_app, "%s")) {
    replace(helper_app, "%s", tempfile);
} else {
    strcat(helper_app, tempfile);
}

Comment 1

[sairuh (rarely reading bugmail)]

->mscott?

Comment 2

[Christopher Hoess (gone)]

*** Bug 92142 has been marked as a duplicate of this bug. ***

Comment 3

[Boris Zbarsky [:bzbarsky]]

I think I agree that we need to append the filename if no %s is used.  One
thing, though.  From the mailcap manpage:

  If no "%s" appears in the command field, then instead of placing the message
  body in a temporary file, metamail will pass the body to the command on the
  standard input. This is helpful in saving /tmp file space, but can be
  problematic for window-oriented applications under some window systems such
  as MGR.

I feel that the justification for sticking to spec on this one is slim,
especially since we don't have a good way to pass in the contents to the app on
stdin with the current helper architecture in Mozilla.  But I thought I'd throw
this out there...

Comment 4

[David Härdeman]

If this is done, please check for more than the occurance of %s before you add
%s to the end of the command.

For instance: I usually have the URL of MP3's appended to the playlist of XMMS
when I click on them.
The mailcap line looks like this:
audio/mpeg;xmms -e '%u'

This is a case where %s doesn't work too good since the "xmms -e" command exits
immediately after adding the file to the playlist if xmms is already running.

By the way...the mailcap standard (not the manpage but
http://www.ietf.org/rfc/rfc1524.txt) says nothing for or against adding %s

Comment 5

[Boris Zbarsky [:bzbarsky]]

So... what is the expected behavior for %u (which is not mentioned anywhere in
the mailcap standard or mailcap documentation)?

I've seen it used in the RealPlayer mailcap lines, and I'm not quite sure what
to do with it, to be truthful...  Would it make sense to just treat %u as
equivalent to %s?

Comment 6

[Austin Donnelly]

I'm guessing %u is the URL clicked on?

Comment 7

[David Hallowell]

This isn't an RFE this is a 4.x parity bug and is a major limitation with helper
apps.

Comment 8

[Jesse Ruderman]

A friend from Pitzer just asked me why he couldn't get helper apps for pdf and
ps to work in Mozilla on SunOS.  He used 'acroread %s' and 'ggv %s' as helper
app entries because that's how Netscape 4 had them.  Both acroread and ggv would
exit immediately with those settings.  I was only able to help him solve the
problem because I was used to not seeing %s in the "what do you want to do with
this file?" dialog on Windows.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Jesse, is your friend editing his Mozilla settings or his Netscape settings? 
The Mozilla settings are unlikely to support %s until bug 78919 (complete
redesign of the helper app stuff) is fixed.  %s support in actual mailcap
entries will happen much sooner than that....

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 142534 has been marked as a duplicate of this bug. ***

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Comment 13

[:Gijs (he/him)]

Think this is just a straight dupe of bug 57420 at this point. But given it's been 20+ years, not sure how likely this is to be worked on. On Windows you can workaround by marking whatever app the default app for that filetype using the OS (where the registry offers complete control over the commandline). On all OSes, workarounds using simple shell scripts or similar are already possible. At one point people suggested we should just delegate to the OS and remove support for custom executables entirely, so I doubt that adding features to the custom handler code will receive traction in future.