Open Bug 515053 Opened 15 years ago Updated 1 month ago

Can't open properties of finished downloads when set to close on finish

Categories

(SeaMonkey :: Download & File Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

REOPENED
Future

People

(Reporter: neil, Unassigned)

References

Details

Attachments

(2 files, 2 obsolete files)

When downloads are set to close on finish, opening finished downloads from the Download Manager doesn't work, because they immediately close themselves :-(

The close on finish checkbox and code should not be visible or active when the reason is REASON_USER_INTERACTED.
I had my simplistic view of how to fix what the summary says, so I implemented that, but I just read comment #0 again and it might be imply that it should possibly done differently and/or even more should be done here.
I'm attaching the patch anyhow as it is at least a possible solution to the core problem.
Assignee: nobody → kairo
Status: NEW → ASSIGNED
Attachment #426409 - Flags: review?(neil)
Comment on attachment 426409 [details] [diff] [review]
patch v1: simplistic way of fixing what summary says

Sorry, this doesn't actually guarantee that the dialog was opened interactively.
Attachment #426409 - Flags: review?(neil) → review-
(In reply to comment #0)
> The close on finish checkbox and code should not be visible or active when the
> reason is REASON_USER_INTERACTED.
The reason should be in window.arguments[1]; alternatively window.opener should not be null when the progress dialog is opened from the download manager.
Actually, after looking at the DMUI IDL, I decided to use REASON_NEW_DOWNLOAD in the end, as that is the only reason when we should actually close the window during load when it's already finished.

This is the first part that only fixes the core problem, I'm keeping this separate because I feel we should bring just this part up to 1.9.1, while hiding the checkbox when opened as "Properties" should be trunk-only.
Attachment #426409 - Attachment is obsolete: true
Attachment #426548 - Flags: review?(neil)
This second part to hide the checkbox when not called for a new download is based upon the current bug 513691 patch, needing to put the flex on a spacer so that the icons still get shifted to the right even when the checkbox is hidden.
Attachment #426553 - Flags: review?(neil)
Comment on attachment 426548 [details] [diff] [review]
part1, v2: fix core issue using reason constant

>   gDownload = window.arguments[0].QueryInterface(Components.interfaces.nsIDownload);
>+  var aReason = window.arguments[1];
Nit: bad choice of variable name.
Attachment #426548 - Flags: review?(neil) → review+
Comment on attachment 426553 [details] [diff] [review]
part2, v1: hide checkbox when opened as "properties"

>+  gCloseWhenDone.hidden = (aReason != nsIDownloadManagerUI.REASON_NEW_DOWNLOAD);
The problem here is that if you open the progress window for an active download from the download manager, it still closes when the download completes.
Attachment #426553 - Flags: review?(neil) → review-
Comment on attachment 426553 [details] [diff] [review]
part2, v1: hide checkbox when opened as "properties"

And if the window doesn't close when the download completes, then all the buttons are hidden leaving a blank area.
Of course that's only a problem with the new location of the buttons...
(In reply to comment #9)
> (From update of attachment 426553 [details] [diff] [review])
> And if the window doesn't close when the download completes, then all the
> buttons are hidden leaving a blank area.

I really don't think we can do anything about that with the current layout - at least not right now. I still think we should have an open icon there for finished downloads, but I'd like to put that work into yet another bug.
Putting all my progress window work into the future for now, see bug 513691 comment #68.
Assignee: kairo → nobody
Target Milestone: --- → Future
Status: ASSIGNED → NEW
And closing this as it shows up in a radar of "bugs where I did patches but the bug isn't resolved"). Some part here was fixed, anything else that someone thinks should be done should go in its own bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Not fixed, because even reviewed patch never landed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #9386654 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: