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.
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 :)
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
17 years ago
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..
17 years ago
Depends on: 137339
16 years ago
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.
16 years ago
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.
Assignee: bzbarsky → nobody
Priority: P3 → --
Target Milestone: Future → ---
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.