415441 - "Open with" saves the file temporary

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[dan_500]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11
Build Identifier: 

If i want to use a file from a link with an other application, the other application will not know the original URL, because the application only know the  temporary local location. "Open with" saves the file temporary. It should not.

Reproducible: Always

Steps to Reproduce:
1. Klick on a link to a file, which has a mime-type firefox does not support.
   e.g. data:application/x-archive,
   or
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/linux-i686/xulrunner-1.8.1.3.en-US.linux-i686.tar.gz
2. Choose your favorite application for this file with "Open with"
Actual Results:  
The file will be saved temporary and the your application will open the temporary file.

Expected Results:  
The file should not be saved temporary. Firefox should refer the URL to the other application.

Good applications can handle a URL. e.g. Firefox, file-roller, gedit and a lot of other applications.

I can save the file directly on the FTP-Server, if the application has the original URL. :-)

Comment 1

[Jo Hermans]

(In reply to comment #0)
> Good applications can handle a URL. e.g. Firefox, file-roller, gedit and a lot
> of other applications.

This will not work until there's a way to know which applications can open a url (so they're reponsible for the download), and which don't (so they need the temporary file).

Comment 2

[Matthias Versen [:Matti]]

90% of all helper applications on win32 can't use an URL. There is no way for Firefox to know if an application can handle an URl.

marking invalid (because it doesn't work in most cases without helper application)

Comment 3

[[:Cww]]

Try: https://addons.mozilla.org/en-US/firefox/addon/81

Comment 4

[dan_500]

90% of all applications on GNU/Linux can use an URL. So
Firefox must not know if an application can handle an URL. In this case - if the application can not use an URL - the user can easily download the file and click on it.

If I want to watch a movie, I must copy the URL in my music player and I can't easily click on a link. :-( I want just click. :-)

Comment 5

[dan_500]

No, Launchy is a bad addon for this. Please build a option for this in firefox. I do not want to use a addon. (And there is no addon for this)

Comment 6

[Jo Hermans]

(In reply to comment #5)
> No, Launchy is a bad addon for this. Please build a option for this in firefox.
> I do not want to use a addon. (And there is no addon for this)
> 

Opening URL's in other applications is exactly what Launchy is used for.

Comment 7

[Matthias Versen [:Matti]]

90% is not 100% and that means that 10% of all cases are failing and that is not acceptable for normal users. If you want streaming media (mp3, Video) then can install a plugin and Firefox will stream the media. If I site wants a user to stream music, then you can download a playlist (.pls) and the helper application will stream the music file.
There is an addon (launchy) for the few users who want this. And addons are just for the case that a few users needs special things like you in this case.

marking invalid because this is no bug, it's by design.

Comment 8

[dan_500]

Firefox should know, that Thunderbird and Sunbird can handle an URL. For all applications see: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
The Core should handle this standard.

So Firefox can detect URL, if an application can handle an URL, with an Desktop Entry:
 Exec=gedit %U
%U will be replace with an URL.

freedesktop.org is a great project. :-)

Comment 9

[dan_500]

Please confirm this bug. If you have no rights to write on the temporary path, you can't open an URL. If url handling were supportet, you can watch a movie without waiting to the end of the download. Or you can hear internet radio. URL handling is a great feature. Please fix it for Firefox 3!

Comment 10

[dan_500]

May use GAppInfo for this.

Comment 11

[cmtalbert]

Not having rights to write to a temporary location should be another bug. We prefer to handle one issue per bug otherwise the system quickly deteriorates into uselessness.  

Firefox 3 can already use internet radio and watch movies online without any issue. So, I don't think that's a valid argument for your point.

GAppInfo is a gnome library.  If we were going to make such a core change, we'd need to make it on every platform.

The original report here is disagreeing with a feature that we have created this way because downloading and then opening always works. So, per the original RFE, we are marking this bug as INVALID.

I think we have talked this issue to death. Please do not reopen.

Comment 12

[Pino Toscano]

Hi,

could this bug be reopen at least as ehancement?

If Firefox should not depend on gnome libraries, it could at least manage .desktop files of Type=Application in an own way (on UNIX only, of course).
Always downloading the file locally can cause other interaction problems with the applications launched. Examples:
- bug #437767 (local file being removed under the application's feet)
- the application could have a "reload" file function, that of course is broken because a local file is passed instead of the remote file
- applications that have some "recent file" function cannot track the open files properly

Comment 13

[dan_500]

I tried to open documents on servers with ftp and http with xdg-open. The preferred application was "gnome-terminal -x nano". Note that this application does not support to open an URL. Anyway it works perfectly, because of the GVFS FUSE mount on ~/.gvfs . Note that you have to disable firefox as http url handler to use gvfs as http url handler. If you use an application which supports to open an URL, it does work perfectly, too.

So as a workaround you could use xdg-open. The cons is you can't use it for non-preferred applications.

--

I think firefox already does read the Desktop Entry, doesn't it? (Or how does it know the commands without any gnome library?)
So just implement the %u feature. Only a little patch, no library needed.

Comment 14

[dan_500]

Oh, sorry, I forgot the cookies.

Comment 15

[Pino Toscano]

I still consider the current behaviour broken, for the reasons I said in comment #12.

Firefox, under Linux, should make use of the XDG standards (Desktop base + Desktop Entry, in this case), and determine whether applications are able to handle remote URLs by themselves. This way, Firefox should not need to do any download by itself for applications (like most of the modern KDE and GNOME applications, at least!) which handle %U and %u.

Please reopen this bug, at least as a wish.