Sorry if this doesn't fit under Plug-ins, but it's the closest category I could find. Ordinarily, downloading a document to a temporary file and then passing that file to the helper application is not a problem. However, there are certain circumstances in which it would be more useful to pass the URL to the helper application instead of the file. For example: following a link to a WAP page on an HTTP server. Since Mozilla can't handle text/vnd.wap.wml, it passes it to a helper application. The WML browser registered as the helper app loads the temporary file, but all the links in the WML file are relative (to save much-needed space), and point to the local temporary directory instead of the server. If Mozilla passed the URL instead, the WML helper app could use it in its actual context. Obviously this would not be desirable on everything, but it could be a useful option for certain types.

Over to mscott.

Marking NEW.

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

Also with mp3 files and pls (radio) files. If Mozilla would sent the url to Winamp, Winamp would stream it for me. That's would be cool. Goto www.shoutcast.com for an example.

This would result in two connections to the server, one from Mozilla and one from the helper app. Is that a problem?

> This would result in two connections to the server, one from Mozilla and one > from the helper app. Mozilla should never fetch the URL in question.

Comments from bug 115041 apply here as well.

I think two connections are necessary. (one in Mozilla (to get the MimeType) and one in HelperApp) Mozilla should start the request, but as soon as the reply arrives, Mozilla verifies that the mime-type of the response is handled through a HelperApp. So, the request operation is immediately canceled and the Helper-App is executed with the URL as parameter.

Making 2 connections can cause confusion and/or unnecessary load on the server side. Maybe an architecture allowing to configure for both possibilities (file extension and header mime type) is possible. Like checking first against a list of known filename extensions and if there is no match, go for the mimetype in the header. So there would be a possibility to configure for both modes and the user can customize it in the way he wants. If he wants full headerbased resolving, he just leaves the list empty, otherwise he can put the filename extensions in the list.

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

Hi, for me, this enhancement is pretty important because it allows for streaming support as well as WebDAV (see bug 115041, which is for me a duplicate, like quite some other bugs related). Basically it's for me all about "URL passing" (just give the URL to the helper) vs. "File passing" (download a file and pass it locally to the helper). For me, it would be enough in a first step to have a new sub-menu in the context menu of URLs "Pass URL to...", and below a list of possible applications, which could be entered in a new Preference category.

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

Mozilla's lack of this feature is part of this article: "Why The Web Sucks" at http://nothings.org/writing/websucks.html

Is it possible for Mozilla to use the Accept HTTP header to block specific mime types delegated to external handlers? According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html this looks doable with q=0. Two retrievals could thereby be avoided from showing up in a web server's access log as "200" successes. How this works with dynamic content and the variety of web servers out there, I have no idea.

Ping! Anybody out there? This bug is annoying me for a long time. Why can't we integrate an option "open URL directly" if the user selected to open the file with an application in the change download action dialog? I'll attach a screenshot showing how Opera is dealing with this. Thanks!

This can probably be accomodated by a plugin like Launchy (https://addons.mozilla.org/firefox/81/), but I'd personally very much like to see it as a core browser functionality. It's probably not wise to assume that the browser knows best how to deal with all kinds of URLs - with webdav integration being one of the obvious uses for passing the responsibility directly to a configured external application.

I'd like to mark bug #137339 and bug #225882 as duplicates. I'd also change the title to "Allow sending URLs directly to associated apps instead of download + open". How do I get the neccesary permissions? Or could someone else please do it? BTW I like the proposal in https://bugzilla.mozilla.org/show_bug.cgi?id=225882#c19 . Thanks.

I'm not sure where this bug belongs but it isn't core:plugins.