Closed
Bug 98797
Opened 23 years ago
Closed 23 years ago
"keep this window" in download progress dialog checkbox should be selectable
Categories
(Core Graveyard :: File Handling, defect)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.6
People
(Reporter: bugzilla, Assigned: law)
References
Details
(Keywords: access, regression, relnote, Whiteboard: [PDT+] [Fixed on trunk] [Need Fix on 094 branch])
Attachments
(1 file)
(deleted),
patch
|
mscott
:
superreview+
|
Details | Diff | Splinter Review |
spun off from bug 91605, basically to undo the change there.
i 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.
repeating from 91650:
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. clicking the Reset button doesn't forget
the decision for the progress dialog, --since Reset only works for remembering
the helper app dialog.
Reporter | ||
Comment 1•23 years ago
|
||
nominating for 0.9.5 --also, prolly add a relnote for 0.9.4.
Blocks: 78106
Reporter | ||
Comment 2•23 years ago
|
||
also noticed that this kills keyboard accessibility --once this item becomes
disabled i cannot even click to bring a widget in focus [which would then allow
me to tab around]. at least on the Mac.
aaronl or bill, would you be able to fix this by backing out the stuff from bug
91605?
Assignee: law → aaronl
Keywords: access
Reporter | ||
Updated•23 years ago
|
Severity: normal → major
I've included a one-line patch for this bug in an attachment to bug 67803.
There's also some other stuff done that might related to this bug. Basically,
when the download completes, focus switches to the Close button (but this
checkbox remains enabled).
Reporter | ||
Comment 5•23 years ago
|
||
spam: over to File Handling.
Component: XP Apps: GUI Features → File Handling
fixed (along with bug 67803)
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 7•23 years ago
|
||
re-opening for the branch. Esther and I just discovered the checkbox is disabled
on the branch. Looks like bill just checked the fix into the trunk. This
prevents the user from being able to determine if they want the progress dialog
to stay up after downloading content. This worked in 6.1. I'm not sure I
understand why someone disabled this checkbox. here's the line of JS that needs
to be removed:
In setupPostProgressUI (helperAppDldProgress.js
keepProgressWindowUpBox.disabled = true;
It looks like jag added this line when fixing 79889 which was to make sure the
progress dialog gets clipped. I'm not sure I understand why he added this line
since disabling this widget should have had no effect on clipping the dialog.
Status: RESOLVED → REOPENED
Keywords: nsbranch
Resolution: FIXED → ---
Whiteboard: PDT [Fixed on trunk]
Comment 8•23 years ago
|
||
See Sarah's initial comment on how it got disabled.
Will the nsbranch keyword change to nsbranch+ at some point? That's what I'm
looking for to know what has to be done ASAP.
Comment 10•23 years ago
|
||
Peter's the lucky guy that can turn it to a nsBranch+ bug. I don't have the power.
Comment 12•23 years ago
|
||
can we get some reviews, and see if this can get in before monday's build?
Whiteboard: PDT [Fixed on trunk] → [PDT] [Fixed on trunk]
Comment 13•23 years ago
|
||
Comment on attachment 53369 [details] [diff] [review]
Bill's one line fix for the branch
since I go this fix from Bill's checkin, I'll sr this patch.
Attachment #53369 -
Flags: superreview+
Comment 14•23 years ago
|
||
Gonna PDT+ this one, pending positive review. Pls try and get it in before
Sunday evening, so it is in Monday's build.
Whiteboard: [PDT] [Fixed on trunk] → [PDT+] [Fixed on trunk]
Comment 15•23 years ago
|
||
Did this get in last night?
Comment 16•23 years ago
|
||
sadly it didn't...it's still in need of an r=.....
Comment 17•23 years ago
|
||
rats! how soon can we get an r=?
Whiteboard: [PDT+] [Fixed on trunk] → [PDT+] [Fixed on trunk] [Need Fix on 094 branch]
Comment 18•23 years ago
|
||
Umm...r=blake, it's a little surprising to me though that this is such an
end-of-the-world stop-ship blocker, given that the checkbox only enables upon
download completion, and I don't think that the number of users on broadband +
the numbers downloading files so small they have no chance to check the checkbox
+ the number of users dying to check the checkbox is so large that it's so
important. But anyways...
Comment 19•23 years ago
|
||
enables -> disables obviously. spam is yummy.
Comment 20•23 years ago
|
||
Pls get this in tonight, for tomorrow's build - PDT+, we are respinning for
another bug, assuming you get a positive review.
Comment 21•23 years ago
|
||
Jaime - I believe all the reviews are there (r=blake, sr=mscott)
Comment 22•23 years ago
|
||
who can check this in for bill?
Comment 23•23 years ago
|
||
I checked this into the branch tonight for Bill.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 24•23 years ago
|
||
vrfy fixed using 0.9.4-branch comm bits on linux, winNT and mac os 10.1. adding
vtrunk kw.
Keywords: vtrunk
Reporter | ||
Comment 25•23 years ago
|
||
vrfy fixed using 2001.10.22.1x-trunk comm bits on mac 10.1, winNT and linux rh6.2.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•