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

NEW
Unassigned

Status

()

Core
General
--
enhancement
16 years ago
6 years ago

People

(Reporter: Kelson, Unassigned)

Tracking

(Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

16 years ago
Over to mscott.
Assignee: av → mscott

Comment 2

16 years ago
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. ***

Comment 4

16 years ago
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

16 years ago
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

Comment 6

15 years ago
> 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

15 years ago
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.  

Updated

15 years ago
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

Comment 9

15 years ago
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

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

Comment 11

14 years ago
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

Comment 13

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

Comment 14

12 years ago
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

10 years ago
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

10 years ago
Created attachment 258643 [details]
Screenshot of Opera's "Pass web address directly to application"  option

Comment 17

10 years ago
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

10 years ago
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.

Updated

10 years ago
Duplicate of this bug: 403723

Comment 20

6 years ago
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.