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
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.
9 years ago
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.
In fact, I would call this a dupe of bug 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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 782743
Ehr, not a dupe, similar issue but different actions. Sorry for spam.
Status: RESOLVED → REOPENED
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? Thanks!
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:  https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/content/downloads.js#1107  https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/content/allDownloadsViewOverlay.js#321 There is another piece of code with a similar isCommandEnabled but doesn't check if the file exists:  https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/DownloadsViewUI.jsm#348 I don't completely understand why the logic isn't more shared, and even is different. For example in  we use `this.download.target.exists` but in  we use `new FileUtils.File(this.download.target.path).exists()`. Not sure what the difference is, maybe we don't have access to .target.exists in  ? Also I'm not sure when the code in  or  does run. In the file , we could possibly change at  (adding a "else") and  (remove the call to isCommandEnabled as it's already done at ).  https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/content/downloads.js#1145  https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/content/downloads.js#1212 In the file , we could do similar changes at    https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/content/allDownloadsViewOverlay.js#1240  https://dxr.mozilla.org/mozilla-central/rev/d38d06f85ef59c5dbb5d4a1a8d895957a78714de/browser/components/downloads/content/allDownloadsViewOverlay.js#409
You need to log in before you can comment on or make changes to this bug.