Closed
Bug 91605
Opened 23 years ago
Closed 23 years ago
File downloads: "Keep this window" checkbox should be unselectable after download
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
INVALID
mozilla0.9.4
People
(Reporter: benc, Assigned: bugzilla)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Noticed this for a while, esp:
Win32 and MacOS 2001-07-17-xx-0.9.2
STEPS:
Download a file that is reasonably large.
Check the "keep this window" checkbox.
Wait for the download to complete.
OBSERVED BEHAVIOR:
You can check/uncheck the box after the download is complete.
EXPECTED BEHAVIOR:
Since the checkbox is not useful anymore, it should go grey, remain checked.
Assignee | ||
Comment 1•23 years ago
|
||
usability/polish, 0.9.4.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Assignee | ||
Comment 2•23 years ago
|
||
Assignee | ||
Comment 3•23 years ago
|
||
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 4•23 years ago
|
||
You know the reason for that delay don't you?
When saving something that happened to be cached, the dialog would disappear so
fast that the user wouldn't see it at all and then they wouldn't understand that
the download was completed successfully and go to another program to download
the file.
Comment 5•23 years ago
|
||
It's explained in the comments he removed,
so I assume that Blake saw it!
I really don't agree with this behavior. I think that the checkbox is very
useful after the download is complete.
The box is always checked by default on a new profile (at least it has been for
me) and now the only way to make the download dialog go away when it's done is
to download a large file and uncheck the box while the file is downloading...
until then I have to manually close countless download dialogs from realaudio files.
... 2001081009/Linux FWIW
Comment 7•23 years ago
|
||
dave raises an excellent point, so i'm reopening so that we could reconsider
backing out this fix.
comments?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 8•23 years ago
|
||
This is marked as "trivial", so I propose we move it out of 0.9.4 for now.
German/Todd ~ What's your vote on this one?
Comment 9•23 years ago
|
||
claudius, this might be the issue that had run into today.
any chance of backing this out?
the current way/workaround to be able to select [turn back on] this checkbox is
to initiate a longish download --so that the progress dialog persists long
enough to allow the user to change it. [claudius: btw, clicking the Reset button
doesn't forget the decision for the progress dialog, --Reset only works for
remembering the helper app dialog.]
Severity: trivial → normal
Keywords: mozilla0.9.4,
nsbranch
Comment 10•23 years ago
|
||
i can wait till moz0.9.5 --nearly forgot how non-trivial it could be to even do
a backout at this stage. :)
Keywords: mozilla0.9.5
Comment 11•23 years ago
|
||
addendum: so, if this could be backed out from the trunk, that'd be fine by me.
Comment 12•23 years ago
|
||
chatted with benc about this: he didn't realize that the decision of
selecting/deselecting the "keep this window" checkbox would persist [across
sessions, even] in future instances of the download progress dialog.
hence, am gonna resolve this as invalid. decided to file a new one to backout
this change: bug 98797.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: mozilla0.9.4,
mozilla0.9.5,
nsbranch
Resolution: --- → INVALID
Comment 14•23 years ago
|
||
vanbalen@rocketmail.com, the problem with realaudio/realvideo download windows
sticking around could also be fixed by bug 102277.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•