Closed
Bug 305982
Opened 19 years ago
Closed 17 years ago
split download manager list into "active downloads" and "completed downloads"
Categories
(Toolkit :: Downloads API, enhancement)
Toolkit
Downloads API
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha8
People
(Reporter: u130342, Assigned: sdwilsh)
References
Details
(Keywords: uiwanted)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
When the download list grows (100+) the browser gets unresponsible when
downloading a number of files (10 or so). Afterclosing the download mgr it's ok
again.
I believe this is caused by the updating of the download progressbars.
The number of items to update can be reduced by moving the completed items into
a separate list (which then can be eaysily sorted, by name, date etc).
Reproducible: Always
Steps to Reproduce:
1. download a lot of files
2. download many files the same time
3. open download manager
Actual Results:
had to wait ;)
Expected Results:
should be responsible
Comment 1•19 years ago
|
||
So when you only download one or two single files (also when there are already
100+ items in download manager history) it's not slow?
In theory it is, but the number of refreshes is lower, so it doesn't break down
response time that much.
number of redraws = (total number of items)*(number of refresh requests)
the number of refresh request depends on the number of active downloads and
maybe it grows when the system gets busy - then fragment size gets smaller -
then more refreshes.
Comment 3•18 years ago
|
||
The lockdown on the browser happens for some seconds after you start the download (doesnt matter if you have focus on the manager or not) and increases as the downloads list increases. Clearing the list solves the problem (not optimal solution? :D)
Comment 4•17 years ago
|
||
Confirming as feature request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: uiwanted
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Comment 5•17 years ago
|
||
Instead of splitting into 2 separate windows/lists, perhaps a filter to show only "active" or "completed" (and "failed", "canceled"). Might be something for bug 377792.
Assignee | ||
Updated•17 years ago
|
Target Milestone: --- → Firefox 3 M8
Assignee | ||
Comment 6•17 years ago
|
||
Fixed by Bug 388517.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
Comment 7•17 years ago
|
||
http://litmus.mozilla.org/show_test.cgi?id=4563
in-litmus+
(General testcase; used for Basic Functional Tests in the future; will fill in more tests with specific UI/functionality later...)
Flags: in-litmus? → in-litmus+
Comment 8•17 years ago
|
||
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007081304
Minefield/3.0a8pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007081305
Minefield/3.0a8pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007081304
Minefield/3.0a8pre
Separate impl./UI issues will be spun off into separate bugs.
Verified FIXED.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•