Bugzilla

(In reply to :Gijs (he/him) from comment #4)
> Fixing both of these (ie not showing the option for the default case unless the download is stopped and there is something to delete - download doesn't have to be complete! - and making sure that it works if the download is in progress and is invoked for non-default pref values) seems like the way forward here. Shane, do you have time to work on this?

Yeah, got sidetracked by something else but I'm on it now 👍

(In reply to :Gijs (he/him) from comment #4)
> Fixing both of these (ie not showing the option for the default case unless the download is stopped and there is something to delete - download doesn't have to be complete! - and making sure that it works if the download is in progress and is invoked for non-default pref values) seems like the way forward here. Shane, do you have time to work on this?

Yeah, got sidetracked by something else but I'm on it now 👍

Edit: Actually, it occurred to me that we can delete an in-progress download and make it unclickable as long as we add a new download property (which will support bug 1755570, adding a new label for fx-deleted downloads).

This makes it a bit more complicated and time consuming since we would need to make sure canceled+deleted downloads appear the same and have exactly the same context menu items displayed as stopped+deleted downloads. I think that's not a foregone conclusion because if the download is in progress, it's not `succeeded` or `stopped` or `canceled` at the time it's deleted, which changes how those values will end up when the dust settles. But I will need to look at it more carefully to be sure.

But we can start by just adding the new download property and implementing the new label, and (for the moment) hiding the "Delete" menuitem for in-progress downloads such that user can't create canceled+deleted downloads. So we can land the fix for this bug quickly, and implement the ability to delete in-progress downloads a bit later once we're sure that the UI is perfectly consistent.