Open Bug 90501 Opened 20 years ago Updated 9 years ago

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

Categories

(Core :: General, enhancement)

enhancement
Not set
normal

Tracking

()

People

(Reporter: kelson, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

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.
Assignee: av → mscott
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: RFE: Allow sending URL instead of file to helper app based on content type → [RFE] Allow sending URL instead of file to helper app based on content type
*** 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?
Blocks: 137339
Blocks: 115041
> 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.  
Summary: [RFE] Allow sending URL instead of file to helper app based on content type → Allow sending URL instead of file to helper app based on content type
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. ***
Assignee: mscott → nobody
QA Contact: shrir → core.plugins
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.
Duplicate of this bug: 403723
I'm not sure where this bug belongs but it isn't core:plugins.
Component: Plug-ins → General
QA Contact: plugins → general
You need to log in before you can comment on or make changes to this bug.