Open Bug 115041 Opened 23 years ago Updated 2 years ago

support %u in mailcap helpers

Categories

(Firefox :: File Handling, enhancement)

x86
All
enhancement

Tracking

()

People

(Reporter: david, Unassigned)

References

(Depends on 2 open bugs)

Details

Currently in older browsers (like Netscape 4.X) if you have a mailcap entry like:
audio/mpeg;xterm -e mpg123 \'%u\'

The file would still be downloaded before the helper app even though it's
obvious from the command that it will never be used (obvious since no %s is
included). In such cases mozilla should spawn the helper app immediately without
downloading the file.
Depends on: 52441, 78919, 83305, 95091
I'm afraid that this is _completely_ impossible with the existing architecture.  

What is '%u' supposed to mean exactly?  I can find no mentions of it in any of
the mailcap standards/documentation; the only apps that use it are RealPlayer
and XMMS (and I bet the latter just aped the former).
Status: UNCONFIRMED → NEW
Ever confirmed: true
%u is URL and Netscape 4.X supports it.

It should be supported (even if I can understand that the target milestone will
be something like > 5.0.0) since some apps can do cool stuff with the help of
the original URL.
Hmmm.  Would listing a file:// url instead of a filename make these apps' behave
better?  That should be doable in the near-term.

The other will take some time, yes.  :)
Assignee: law → bzbarsky
I don't think the file:// part would make any difference, all the "%u-apps" I've
used can work with %s as well, the only reason that "no-download" would be good
is because you could then pass the URL to an MP3 for instance and the app would
slowly download/play it in parallell (which works fine for a few kbyte/s stream). 

As it is now you'd have to wait for the entire file to be downloaded...*then*
listen to it.

So...it's not really an error with the applications or anything, just that it
would be a nifty feature which you could do "cool stuff" with :)
Blocks: 78106
What is the advantage of handling these applications an URL? If it is only
streaming, that could be realised differently, too (pipes, or whatever similar
mechanism your OS supports).

The %u approach is nonstandard and not particularly well thought-out. What URL
schemes is the application able to retrieve? http surely, file and ftp probably,
what about gopher, news, etc. To do this cleanly, one would have to provide
information about supported URL schemes.

And this is ignoring the fact that you have one of the more comprehensive URL
fetchers already running.
Well, it's hard to pre-guess all the uses it could have. As of today it's mostly
used by realplayer and VRML applications but it could be used for many other
things. Say for instance that you click on that 200Mb MPEG film on your buddys
webserver, now wouldn't it be much nicer to have a movie player pop up instantly
that in a buffered mode plays what it's got so far instead of having to download
the entire file first. 

There are probably many other apps that in one way or another could have use for
the original URL of the resource you're downloading.

Remember that the entire %u part is very much optional but cool stuff could be
done with it, it doesn't hurt in any way and it already exists in 4.7 (pp bug?)
resummarizing to make it clear what the bug is about
Summary: Mailcap or "helper application" without %s shouldn't be downloaded → support %u in mailcap helpers
Priority: -- → P5
Target Milestone: --- → Future
This is needed for audio/video streaming of live streams.  On netscape I have in
my .mailcap

video/x-ms-asf; /usr/local/bin/mplayer -x 2 -y 2 >/dev/null "%u" ;

This works fine on netscape.  Mozilla completely ignores the above line
(presumably because there's no %s in it) and I have to copy/paste the URL to the
command line to play.

There is no way you can pre-download a live stream as it is (theoretically)
infinite length and you'd run out of disk space..
remove self
Depends on: 137339
Depends on: 90501
Apart from streaming (which is very important), a way to ass the URL to a helper
app without downloading it is needed for alternative "download managers". I
don't want to download stuff in the 50MB+ range with Mozilla, but rather use
wget or something similar. I can work around it with Copy Link Location, but
that is clumsy and does not work with some websites (which do "fancy" (read:
bad) stuff like downloads resulting from redirects or forms. I am fighting with
such a site right now.
Comments from bug 90501 apply here as well.
QA Contact: sairuh → petersen
Priority: P5 → P3
*** Bug 207750 has been marked as a duplicate of this bug. ***
My killer-app for %u (in Comm 4.x on UNIX) is so a helper-app can get
the internal link name (the optional trailing #name part of the URL).
For example for framemaker files (binary .fm or ASCII .mif), one
triggers maker to view the file using the fmclient executable, which
takes an optional internal link name (to move the initial display to
that link name position in the file, rather than always page 1 of a
many page reference manual for instance), just like in URL's for
browsers, and named destinations in PDFs.

I believe there isn't another code already giving just the link name
(%l for example)?  The %u is extremely useful for things like this.
Would also be nice to have %m for the mime-type.
QA Contact: chrispetersen → file-handling
Assignee: bzbarsky → nobody
Priority: P3 → --
Target Milestone: Future → ---
Product: Core → Firefox
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.