90501 - Allow sending URL instead of file to helper app based on content type

Status: NEW

(Core :: General, enhancement)

Description

[Kelson]

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.

Comment 1

[av (gone)]

Over to mscott.

Comment 2

[Keyser Sose]

Marking NEW.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 4

[Julius Schwartzenberg]

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.

Comment 5

[Niels Aufbau]

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

Comment 6

[Ben Bucksch (:BenB)]

> 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.

Comment 7

[Ben Bucksch (:BenB)]

Comments from bug 115041 apply here as well.

Comment 8

[Daniel Mario Vega (Restore MNG Support --> #18574)]

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.  

Comment 9

[Christian Franck]

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.

Comment 10

[Tim]

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

Comment 11

[Eric L.]

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.

Comment 12

[Asaf Romano (gone)]

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

Comment 13

[Simon Skrede]

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

Comment 14

[Cowzilla]

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.

Comment 15

[andreruediger]

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!

Comment 16

[andreruediger]

Attachment: Screenshot of Opera's "Pass web address directly to application" option

Comment 17

[Simon Skrede]

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.

Comment 18

[andreruediger]

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.

Comment 20

[Josh Aas]

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