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.

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

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).

Fixed by bug 408565.

Thanks for the bug cleanup, Mardak; verified.

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

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."

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?

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

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

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

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.

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

"in-testsuite?" flag remains