Bugzilla

Oh, actually the file is not being deleted at all. The problem here is that it's pausing the download instead of deleting the file. Originally this worked, I must have tested it dozens of times. I suspect 1750484 regressed the in-progress delete behavior, because that patch changed how we finalize the download. Maybe it's a timing issue.

Oh, actually the file is not being deleted at all. The problem here is that it's pausing the download instead of deleting the file. Originally this worked, I must have tested it dozens of times. I suspect 1750484 regressed the in-progress delete behavior, because that patch changed how we finalize the download. Maybe it's a timing issue.

Originally I did not expect there to ever be a session download item whose target was deleted, because it was intended to delete the file and simultaneously remove the download item. It would all just poof out of existence so this was a lot simpler. Now if there's going to remain a download item after we use the Delete menuitem, then we need to make the Delete menuitem _cancel_ an in-progress download and tell the saver to basically reset everything.

I guess my problem with that is it doesn't make any sense that deleting the download item would result in it displaying as a normal, clickable element. It seems more like we just shouldn't show the Delete menuitem when the download is in progress, unless `browser.download.clearHistoryOnDelete > 0`. However, even in that case (when it clears the session download on delete), it's still failing to delete the file, so that needs to be fixed too.

Oh, actually the file is not being deleted at all. The problem here is that it's pausing the download instead of deleting the file. Originally this worked, I must have tested it dozens of times. I suspect 1750484 regressed the in-progress delete behavior, because that patch changed how we finalize the download. Maybe it's a timing issue.

Originally I did not expect there to ever be a session download item whose target was deleted, because it was intended to delete the file and simultaneously remove the download item. It would all just poof out of existence so this was a lot simpler. Now if there's going to remain a download item after we use the Delete menuitem, then we need to make the Delete menuitem _cancel_ an in-progress download and tell the saver to basically reset everything.

I guess my problem with that is it doesn't make any sense that deleting the download item would result in it displaying as a normal, clickable element. It seems more like we just shouldn't show the Delete menuitem when the download is in progress, unless `browser.download.clearHistoryOnDelete > 0`. However, even in that case (when it clears the session download on delete), it's still failing to delete the file, so that needs to be fixed too.

Honestly I still don't really like the default behavior of `browser.download.clearHistoryOnDelete = 0`, it seems weird to me that it should remain cluttering the session download list. I think a default value of 1 makes more sense. That's where it deletes the session download but keeps the history download, such that it appears in the "all downloads" view (and the download link remains :visited) but does not appear in the downloads panel.