Summary: Download Manager should cache its "Downloads"-window list Currently, even with improvements in the way we build the Download Manager list--see bug 408745 and bug 404006--we still don't cache that list; this means that subsequent Download Manager window invocations will take just as long to populate as their previous ones.
Not blocking, far too late for changes of this type.
Flags: blocking-firefox3? → blocking-firefox3-
When the file list in Downloads is long, users wait up to a few seconds before a new download is performed. Waiting two extra seconds for a download is usually not a problem. However, increasingly people are using Web-pages to control interactive animations like in Bio-molecule graphics. Clicking a Web link results in a certain action in the Software that is controlled by the Web-page. In this case 2 seconds delay for each user interaction is certainly not acceptable. The delay vanishes after clearing list. To my opinion, this performance bug is important. For examples see page http://3d-alignment.eu/strap_script.html http://www.umass.edu/microbio/chime/
The protein viewer Vmd already has the possibility to be controlled by Web-links of the form http://localhost The authors of another protein viewer Pymol currently implementing this feature: "Also, we're in the process of adding web-service interface to PyMOL as well, so you will soon simply be able message PyMOL with are URL request like: http://localhost:port/color.pymol?color=red&selection=name%20ca" Therefore it would be helpful if the delay of the downloads manager could be improved.
Shawn, anything we can do to improve the time needed to enqueue a new download?
I'm not seeing this delay myself, nor do I see code that would cause it (short of network latency)
Christoph, could you attach a prepared downloads.sqlite file which shows this behavior? It's sometimes easier to have a testcase to confirm the behavior. Thanks.
(In reply to comment #6) > Christoph, could you attach a prepared downloads.sqlite file which shows this > behavior? It's sometimes easier to have a testcase to confirm the behavior. > Thanks. Christoph appears to be gone
You need to log in before you can comment on or make changes to this bug.