Open Bug 782944 Opened 9 years ago Updated 4 years ago

trying to open a file from downloads list that has been deleted silently fails


(Firefox :: Downloads Panel, enhancement)

Not set



Tracking Status
firefox17 - affected


(Reporter: vlad, Unassigned)


(Blocks 1 open bug)


If you have a file in the downloads list that got deleted from the disk somehow, trying to open it or show it in the file manager just causes silent failure.  We should do something smarter here, such as showing an error message and graying out the item in the downloads list.
Any ideas on who can take this on? Tracking for now as a nice-to-have when we ship Firefox 17 though I can't see us blocking the release on this unless 'silent failure' was a crash/hang.
I would like to work on this bug.
We're a week away from merge to Beta - adding qawanted so we can track down when this might have regressed to help decide if we will continue tracking this for 17.
I'm not sure this is a regression. As far as I know, this has been the behavior forever, and it definitely is in Release.

See also Bug 726451
This is not a regression, it's always behaved this way. I tested Firefox 19.0a1 and Firefox 4.0 to confirm. I personally don't think this needs to be tracked for any release.
Severity: normal → enhancement
OS: Windows 7 → All
Hardware: x86_64 → All
In fact, I would call this a dupe of bug 726451.
Blocks: 726451
If it's been present all that time it's definitely not something we'll track for FF17, Arpit you should go ahead and take this bug and work on it - when there's a fix we may consider it for uplift depending on risk.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 782743
Ehr, not a dupe, similar issue but different actions. Sorry for spam.
Resolution: DUPLICATE → ---
Hey, I'd like to work on this bug. Just in case, what type of "Error" should I use here? Alert Box or what? Maybe some small CSS is enough? Some text?

This is still happening in Firefox 51 (Build ID 20161110004022).

I think any type of message would already be better than doing nothing. Maybe trying doing something simple first just as a proof of concept and we can take if from there ?

Mahdi, it's been a long time since your last message, not sure if you'd still want to work on this ?
Note we already have some code to do this check somewhere, because the context menu does disable the matching items when appropriate.
I found 2 pieces of code that I think is doing this:


There is another piece of code with a similar isCommandEnabled but doesn't check if the file exists:

I don't completely understand why the logic isn't more shared, and even is different. For example in [2] we use `` but in [1] we use `new FileUtils.File(`. Not sure what the difference is, maybe we don't have access to .target.exists in [1] ?

Also I'm not sure when the code in [1] or [2] does run.

In the file [1], we could possibly change at [4] (adding a "else") and [5] (remove the call to isCommandEnabled as it's already done at [4]).


In the file [2], we could do similar changes at [6] [7]
You need to log in before you can comment on or make changes to this bug.