Closed Bug 249654 Opened 18 years ago Closed 18 years ago

Open finished download not working on linux

Categories

(Toolkit :: Downloads API, defect, P2)

All
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: ang3l0, Assigned: dmosedale)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(2 files, 5 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040629 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040629 Firefox/0.9.1

Trying to open a finished download doesn't work on linux.

It doesn't work using open link and neither using open in the context menu

Reproducible: Always
Steps to Reproduce:
1. Download a file
2. Once finished try to open via the link
3. Try also using the context menu

Actual Results:  
Nothing happens

Expected Results:  
Use default program to open it or popup a program selection dialog
Yep.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0?
Just to clarify, neither double click nor context menu options work to open the
file.
*** Bug 249786 has been marked as a duplicate of this bug. ***
Related to bug 232138?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Priority: -- → P2
I don't think this is a problem on Mac. but is this an issue on Windows?
Windows works.
Hardware: All → PC
Assignee: bugs → mconnor
nsIFile.reveal doesn't work on GTK

If I can find time, I'll post the incomplete diff that fixes show folder in the
dlmgr and in options, but opening the file directly needs some mucking around.
I'm guessing bug 67001 is quite related to this one.
Can we get an alternate patch to disable all this UI for GTK? 
Keywords: helpwanted
I know we try to stay away from Gnome and just use GTK, but a solution without
too much "mucking around" for Gnome users might be to call the gnome-open
program. It takes an argument of an URL to open (in this case a file: url) and
then opens it with Gnome's default handler for that type. It's what Gaim uses to
open links in Gnome's default browser.

The source is here, but if we used the source rather than calling it we'd have
to link with more than libgtk:
http://cvs.gnome.org/viewcvs/libgnome/libgnome/gnome-open.c?view=markup

This is comparable to KDE's `kfmclient exec file:/foo` but I haven't tracked
that one down in KDE CVS yet. I imagine it would be easy to call out to either
of these programs in much the same way that we call out to whatever program when
the user clicks on an externally-handled link.
Taking, at Ben's request.
Assignee: mconnor → dmose
Status: NEW → ASSIGNED
Keywords: helpwanted
Attached patch patch to disable "open", v1 (obsolete) — Splinter Review
This patch will disable both the link and the context menu item for "open" on
GNOME platforms.
I believe dmose is looking at the "Show" button in dl prefs, too. 
Attachment #162032 - Attachment is obsolete: true
Attachment #162142 - Flags: review?(bugs)
Attachment #162142 - Flags: approval-aviary?
http://lxr.mozilla.org/aviarybranch/source/toolkit/mozapps/downloads/content/downloads.js#815
also needs to be fixed (open containing folder in the DM context menu) in the
same way as Show Folder was.  That, or hidden/disabled a la Open.

It might be worthwhile to consider doing the nsIFile.reveal() bits in a
try/catch, so that if we in future do get working nsIFile.reveal, we'll pick
that up for free.  However, odds are that it would be partial, GTK-version
limited fix like the filepicker etc, so we'd already have the fallback in place
for ANY time the reveal call fails/is unsupported.

Excellent idea re try/catch, Mike.  The code is definitely cleaner this way. 
I've fixed the other instance of reveal that you pointed out as well.  Once
this is reviewed, should I land it on the trunk first and then the branch?
Attachment #162142 - Attachment is obsolete: true
Attachment #162142 - Flags: review?(bugs)
Attachment #162142 - Flags: approval-aviary?
Fixed a couple of comments.
Attachment #162153 - Attachment is obsolete: true
Attachment #162154 - Flags: review?(bugs)
Attachment #162154 - Flags: approval-aviary?
Wouldn't it make more sense to do something along the lines of:

#ifdef XP_GNOME
<!-- reveal is disabled in GNOME -->
#else
real implementation goes here
#endif

That way, the comment shows up in the GNOME build rather in all the non-GNOME
builds, where it wouldn't be relevant.
the less the actual code is different between platforms, the better, IMO.  Plus,
if reveal gets implemented on GTK, we pick this up for free, while leaving the
fallback for cases like the qt port, which isn't GNOME and might get support for
Reveal sooner or later than GTK.
Whiteboard: [have patch] - need review ben
Comment on attachment 162154 [details] [diff] [review]
patch v4: fix "show folder"; disable "open"

a=asa for aviary checkin pending the r=
Attachment #162154 - Flags: approval-aviary? → approval-aviary+
Comment on attachment 162154 [details] [diff] [review]
patch v4: fix "show folder"; disable "open"

This won't work in thunderbird... you need #ifdef MOZ_PHOENIX wrapping the
openDialog calls (just use "chrome://browser/content/browser.xul" - don't worry
about getting the pref - it's only in the Firefox case that you'll be able to
do this anyway... and in in the #else part use the External Protocol service to
open the path as it's done here:

http://lxr.mozilla.org/aviarybranch/source/toolkit/mozapps/extensions/content/e
xtensions.js#57
Attachment #162154 - Flags: review?(bugs) → review-
Attachment #162154 - Flags: approval-aviary+
Whiteboard: [have patch] - need review ben → [have patch] - needs updated patch
dmose, other ideas?
Fixed as per Ben's suggestion.
Attachment #162154 - Attachment is obsolete: true
A funny thing happened on the way to this patch.  Using the external protocol is
the right thing to do, but for a different reason than expected.  It used the
default "file:" handler to open the directory... and the default handler was
Nautilus, not the browser.

So this makes me think that in fact we can fix both "show folder" and "open" by
sending them to the external handler all the time.  New patch forthcoming shortly.
Attachment #162635 - Attachment is obsolete: true
The patch seems to work as expected in both Firefox and Thunderbird.
Comment on attachment 162640 [details] [diff] [review]
patch v6: fix both "show folder" and "open"

Requesting review; carrying forward pending approval.  I propose to check this
in on the trunk as well as the branch, since it actually fixes the real issue.
Attachment #162640 - Flags: review?(bugs)
Attachment #162640 - Flags: approval-aviary+
Whiteboard: [have patch] - needs updated patch → [have patch] - needs review
Hardware: PC → All
Comment on attachment 162640 [details] [diff] [review]
patch v6: fix both "show folder" and "open"

r+a=ben@mozilla.org
Attachment #162640 - Flags: review?(bugs) → review+
Whiteboard: [have patch] - needs review → [have patch] - ready to land
dmose, is this checked in?   needs to go in soon to make the RC1 train
Fix checked in to the both the trunk and the branch.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Whiteboard: [have patch] - ready to land
verified with Linux FF branch build 2004-10-21-09-0.9

Clicking open in the download manager brings up an External Protocol Request
dialog. Clicking Launch application opens the page in FF, since I have set it to
be my default browser.
Status: RESOLVED → VERIFIED
As Tracy points out, this now opens an External Protocol Handler warning dialog,
and people may well want to turn this off by default.  Since it's bad user
experience, and we don't want to train people to turn off this warning, dveditz
suggests whitelisting the file: protocol as far as these warnings go on Unix. 
Patch forthcoming.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Keywords: fixed-aviary1.0
Attachment #162954 - Flags: superreview?(dveditz)
Attachment #162954 - Flags: review?(dveditz)
Attachment #162954 - Flags: approval-aviary?
Comment on attachment 162954 [details] [diff] [review]
patch to get rid of warning, v1

a=asa pending reviews.
Attachment #162954 - Flags: approval-aviary? → approval-aviary+
Comment on attachment 162954 [details] [diff] [review]
patch to get rid of warning, v1

r=dveditz. I don't think this is an area of combined r/sr but sr= too if it is.
Attachment #162954 - Flags: superreview?(dveditz)
Attachment #162954 - Flags: superreview?(darin)
Attachment #162954 - Flags: review?(dveditz)
Attachment #162954 - Flags: review+
*** Bug 249786 has been marked as a duplicate of this bug. ***
Attachment #162954 - Flags: superreview?(darin) → superreview+
Fixed on the branch.  Awaiting trunk opening.
Keywords: fixed-aviary1.0
hmm, I know that Linux is a problem here because its different windowmanagers
and desktop environments. The problem now is that it makes heavy use of GNOME in
GTK2 builds. At least this makes problems if you don't use GNOME at all.
If I use "Show folder" now in Firefox with my windowmanager "WindowMaker" it will
start up many gnome stuff and change my windowmanager's behaviour so it is
unusable without killing those stuff again.
I have no better idea at this point but the current solution makes Firefox
almost a GNOME-only application :-(
Fixed on the trunk.

Wolfgang, the problem is that there's currently no standard way to do this.  It
could perhaps be implemented in a KDE-specific way as an extension.  At some
point, there will hopefully be a standard way to get this info.  The
shared-mimetypes stuff on freedesktop.org is at least a start in the right
direction.  Feel free to file a separate bug on that, if there isn't one already.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.