392446 - If downloaded file is removed, but saved dir still exists, then "Open Containing Folder" menu item should not be greyed out

Status: VERIFIED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007081603 Minefield/3.0a8pre ID:2007081603

Download a file so it is listed in the DM, then delete or move the file from the download directory. If you then right click on the item in the DM, the Open menu item is greyed out (expected) but the Open Containing Folder is also greyed out (for no reason I can think of).

I think if the file has been moved, but the directory it was downloaded to still exists, then the Open Containing Folder menu item shouldn't be greyed out.

Comment 1

[Peter van der Woude [:Peter6]]

I'd rather see the file link/name removed from DM if it's moved/deleted from the folder it was downloaded to.
DM is not intended to track whatever you do (move,delete,rename) with 3rd party programs.
Let's keep it simple please

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

Madhava, can you comment on how (or if) the UI is supposed to change if a file is no longer in the same directory as it was when it was downloaded?

Note that, currently, the context-menu items will gray out when the file is no longer in its original location, but the "Open" button remains active and does nothing when clicked for a file that has been removed or deleted (thanks to Marcia for that rather obvious find that I overlooked).

Comment 3

[Ed Lee :Mardak]

Fixed by bug 408565.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

Thanks for the bug cleanup, Mardak; verified.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

in-litmus+

https://litmus.mozilla.org/show_test.cgi?id=5257

Comment 6

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041215 Minefield/3.0pre ID:2008041215

Is this properly fixed for anyone else? Maybe this should go in another bug, but:

1. New profile, start firefox
2. Go to http://hourly-archive.localgho.st/
3. Right click on a .zip file and choose Save As
4. Choose a location to download the file to.
5. After the file has downloaded, move the file to another folder
6. Open the Download Manager window, right click on the download entry, and choose Open Containing Folder

Expected:
- Folder that file was downloaded to is opened (even tho the file is no longer in there)

Actual:
- Firefox shows an error message: "The path 'D:\Path\To\File\20080414_0314_firefox-3.0pre.en-US.win32.zip' does not exist or is not a directory."

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

I can confirm that this regressed--at least on Windows--for both the case you mentioned above, and the more-common, simple-deletion-then-Open-Containing-Folder case.

Edward, can we get a quick fix for the regression?

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

The regression seems to be only on Windows, from my testing of trunk nightly builds on OS X 10.5 and Ubuntu 7.10.

Comment 9

[Ed Lee :Mardak]

Is this an alert error or error console message with a line number?

Comment 10

[Steve England [:stevee]]

It's a dialog with an [OK] button; the error console reports nothing.

I don't think this is a regression either - it appears to never have worked.

I downloaded a file and moved it from its download location.

With 20071218_1141_firefox-3.0b3pre.en-US.win32 I right click on the entry in the download manager window, and the Open Containing Folder menu item is greyed out.

With 20071218_1311_firefox-3.0b3pre.en-US.win32 I right click on the entry in the download manager window, the Open Containing Folder menu item is clickable, but clicking it throws the error dialog:

/!\ The path 'D:\file.jpg' does not exist or is not a directory. [OK]

Checkins to module PhoenixTinderbox between 2007-12-18 11:41 and 2007-12-18 13:11 :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-18+11%3A41&maxdate=2007-12-18+13%3A11&cvsroot=%2Fcvsroot

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm guessing we pass the full folder and file name to Windows (in order to have it focus the right file) and it spits back an error to us.

This isn't a blocker, but some cleanup would be nice.

(In reply to comment #2)
> Madhava, can you comment on how (or if) the UI is supposed to change if a file
> is no longer in the same directory as it was when it was downloaded?

I agree with comment #1, that having the "Open Containing Folder" enabled is misleading as the file isn't actually contained there. When the file is removed, we should disable this option.

So, I'm not sure how to track this, bugzilla-wise. I think what I want to do it mark this WONTFIX and then file a follow on bug. So that's what I did. See bug 429144.

Comment 12

[Shawn Wilsher :sdwilsh]

verified - I was wondering why we wanted to have it available because of that very reason.

Comment 13

[Wayne Mery (:wsmwk)]

"in-testsuite?" flag remains