GNOME Bugzilla – Bug 326112
Epiphany should not download files when opening in another app
Last modified: 2011-07-28 23:09:42 UTC
Please describe the problem: When clicking on a link to a pdf/video/whatever file which can be handled directly by Ephy, a dialog pops up asking if you want to download or open the file in the associated application. Since more and more of these apps are gnome-vfs aware, Ephy shouldn't download the file before trying to open it, but should directly give the uri to the app when possible. Here are some problems caused by the download : - apps that shows the document title in the title bar (evince, gedit) show "strange" names (/tmp/something) which are totally unrelated to original names. This is quite confusing. - apps don't know the file isn't writable. So you edit the file, save it, and loose it because the app didn't ask you to save the file somewhere else. - for some medias (videos, music), the related app supports streaming. The current way of things requires you to download the whole video before playing it, that is not necessary and annoying Anyway, you should consider than there are apps around there that don't have the gnome-vfs (or kioslave, or...) capabilities. Steps to reproduce: 1. Download some eavy video (e.g. http://gazpacho.sicem.biz/videos/gazpacho_example.mov ) Actual results: Epiphany (1.8.2) downloads the whole file (+10MB) before opening Totem Expected results: Totem runs immediatly to use its streaming capabilities Does this happen every time? 1 Other information:
While it would be nice to have the url opened by the application directly, there are problems. E.g. lots of sites requires cookies to be able to request files, and passing these urls directly to applications causes the app to fail to load the file. An example of a site that behaves like this is: http://www.tgresidential.com/ (click on a "House" link to view the details of the house, and then click the "Property particulars" link) This link is a pdf file which can't be requested directly by an application without a cookie.
Perhaps you could discriminate these special cases by doing a HEAD without sending any cookies. Anyway that's not a good solution since it requires one more HTTP request... Another way to handle the problem would be to make the cookies shared between gnomevfs and epiphany. I think that's what kde does with its KCookieJar.
I've read that konqueror discriminates the network-capable apps and the other ones by looking something in their .desktop file. Maybe the same could be done for Epiphany ?
Needs gecko support too.
*** Bug 559820 has been marked as a duplicate of this bug. ***
"I've read that konqueror discriminates the network-capable apps and the other ones by looking something in their .desktop file. Maybe the same could be done for Epiphany ?" Indeed! Check out g_app_info_launch_uris :) This also gains us more location-sensitive applications. For example, a PDF file may not be readable by Epiphany but it could still be treated in the same way as a web page; that is, being read from a specific location relative to the server. When we download the file and then run an application on the local copy, we lose that location information so any relative links are broken.
I like this idea. And it is easily done with WebKitGTK+, I believe =). I'll maybe try a patch later on.
The reason why it wasn't done in the past is because the other application wouldn't be able to access the original cookies, and you'd lose the referer. So it would break a few websites. The cookie sharing might not be a problem in WebKitGTK+ if both apps use libsoup and it has a cookie jar available for both (I'm not sure that's the case).
(In reply to comment #8) > The reason why it wasn't done in the past is because the other application > wouldn't be able to access the original cookies, and you'd lose the referer. So > it would break a few websites. > > The cookie sharing might not be a problem in WebKitGTK+ if both apps use > libsoup and it has a cookie jar available for both (I'm not sure that's the > case). > There really is no sound cookie sharing mechanism in libsoup right now I think. You'd have to tell both apps to just use the same file, but I don't think the code is really prepared to handle this well, and it's still seems pretty hacky. Maybe the solution would be a DBus service? CCing Dan, which I'm sure has ideas about this.
http://live.gnome.org/LibSoup/DesktopWideHttp has some slightly-abandoned notes on sharing cookies, auth, etc between desktop apps. I believe the sqlite cookie store is in theory shareable between apps, though the current implementation doesn't attempt to do so. (It would probably need to set up a file monitor and watch for changes from other apps? And maybe do some locking? Not sure how much sqlite does automatically here.)
Duping against the newer one because of its UX/UI comments. *** This bug has been marked as a duplicate of bug 605908 ***