Closed
Bug 87113
Opened 23 years ago
Closed 20 years ago
Closing window and repaint takes 12 seconds
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: tpowellmoz, Unassigned)
Details
Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+) Gecko/20010620 on an IBM ThinkPad 770E running win2000, it takes 12 seconds (average on stopwatch) for a second window to close and the previous window to repaint. This makes the browser almost unusable--I tend to browse in new windows a lot. The browser is unresponsive for those 12 seconds. For comparison, IE5.5 on the same laptop takes less than a second to close and repaint the previous window. Switching between windows with Mozilla is quite fast (under a second), so I don't think it's the repaint that's slowing things down. To reproduce: Start browser Browse somewhere Open a link in a new window (optional: switch back and forth between the windows and notice how fast it is) Close the new window Notice how slow it is. I'm not sure what impact the length of your browsing session or the number of windows you've opened and closed has on this. Would it be possible to give the previous window focus and then close the other window in the background to speed things up? There are several bugs that hint at this problem. Bug 28639 suggests a similar delay, but with many windows open. Perhaps this is the same problem? Bug 42321 suggests that the problem may be JavaScript garbage collection. Anything that slows window close is painful when browsing in new windows. Bug 83421 talks about close performance on Linux of ~1sec. I wish! I can't seem to find a bug that's tracking the overall performance slowness of window close on Windows.
Comment 1•23 years ago
|
||
Using Mozilla 2001061520 on win2k. System: Athlon 1GHz with 256MB RAM (arguably good, what about your cpu and ram?) I open Mozilla. I right-click and select "Open link in new window". New window appears. I switch back and forth: more or less half a second for them to repaint. I hit the "X" on the upper right corner of the window. It takes ~1 second to close and show the other window. On a side note, I don't think DOM0 is the right component, but per lack of a better place I'll leave it here.
Reporter | ||
Comment 2•23 years ago
|
||
Computer specs are Pentium II with 128MB RAM. Are Mozilla.org nightly builds debug builds? If so, that might explain some of the delay. However, the striking difference between Mozilla and IE on the same machine is troubling. I just upgraded to 2001062204 and I'm seeing the same slowness for window close.
Comment 3•23 years ago
|
||
Nightlies are non-debug builds.
Comment 4•23 years ago
|
||
A Pentium II 233, 266, 300????? There is a difference. I have a PII 266 128meg RAM running Win2k (SP2) using build 2001063008. The behavior of Mozilla compared to that of IE5.5 is different, but not really any slower. IE5.5 may dispense with the GUI a bit quicker, but overall, an IE5.5 window does not shut down any slower than Mozilla. It is just a matter of perception. If you are used to the way IE5.5 closes its windows and you see Mozilla doing something slighty different, your bias may be more toward liking the way IE does things. It hasn't been a problem for me as of any recent builds. Sure, some very old builds didn't run very fast on my PII at home, but performance in newer builds is quite acceptable now...and I expect it will only get better :-) BTW, on my PIII 350 with 256meg RAM at work, Mozilla just smokes. Given that even the 350Mhz machine is old-hat compared to todays 1Ghz+ machines, and it still runs great, I don't think this bug matters a whole lot. Jake
Reporter | ||
Comment 5•23 years ago
|
||
It looks like this may have been caused by an old profile. It appears that I was using a profile converted from Netscape 4.7x. I just created and used a new profile and Mozilla closes windows quite quickly--roughly 1 second or so, which is very acceptable. I tested the 2001062204 Windows nightly on the same machine/OS with both profiles. The original converted profile remains very slow. The new profile is quite quick. Major differences between the two is that the original profiles has hundreds (if not thousands) of bookmarks. Still, I don't know why that should affect window close! (It does seems to impact startup of the initial window. I imagine that's a dup bug somewhere.) Another thing interesting that I noticed is that the original profile appears to have two IE Favorites folders.
Comment 7•22 years ago
|
||
SEVERITY = LOW [(1)No crash but perflormance is too slow, (2)No functional failure, (3)No Cosmetic failure] VISIBILITY = HIGH [(1)Visibility can be highest because lot of people have habit of opening links in new windows like reporter does. (2)Gets one point of compatibility with other browsers since it works very well on IE] PRIORITY = VISIBILITY * SEVERITY Hence Priority = p3 adding word "qawanted" because I'm setting this priority on available data & if someone feels otherwise then please investigate this more & feel free to change this priority.
Keywords: qawanted
Priority: -- → P3
Comment 8•22 years ago
|
||
Are we doing any better in the meantime?
Comment 9•22 years ago
|
||
I have an Athlon 2000+ with 512 MB RAM, with a 7200 RPM HDD. Switching from one window to another is instantaneous, but closing down a window takes almost a second on average (but gets to two-three seconds on occasion). Every time I close a window I hear my disk crunching the whole time I wait for it to close, although I'm by no means low on memory (~200 MB free on average). And I tend to browse with 7-8 windows open at all times, constantly opening/closing windows - which makes this bug particularly annoying for me.
Comment 10•22 years ago
|
||
This bug may be related to the bug about only saving bookmarks once closing bookmark editor. The time to close the window seems similar to the time it takes to save the bookmarks to disk (when moving a bookmark within the editor). The window closing bug only happens with a full browser window, not a tabbed window. My bookmark file is about 550K, and this is on a slow laptop disk. OS is Win2K Pro. Profile was not converted from previous Netscape or Mozilla, however bookmarks were copied over. Question: Was there a change from Mozilla 1.1 to Mozilla 1.2.1 that caused a close of a secondary browser window to cause a save of the bookmarks?
Comment 11•22 years ago
|
||
Additional information to Comment #10. Between window close and screen redraw, disk activity light is on (and disk activity is audible). Just like moving a bookmark. This is why I believe this bug may be related to saving bookmarks.
Comment 12•21 years ago
|
||
I have this same problem running 1.2.1 (20021130) on Win2K with P4, 2GHz and 524 MB RAM. When I close a browser window (it doesn't seem to do the same with a mail window) Mozilla freezes for several seconds and the hard drive is audibly active. I don't recall exactly when this started but I just got this laptop in late December and loaded Mozilla and then exported / imported my bookmarks from Mozilla on my old laptop into this new one. I do have hundreds of bookmarks. Carter
Comment 13•21 years ago
|
||
For whoever has this problem, you might want to *try* deleting XUL.mfl and/or XUL.mfasl in your profile directory with Mozilla shut down, and then start it again. I made the connection rather late, but this just might be related to bug 169777. In case this seems to fix it, please drop a note on that bug as well stating that.
Comment 15•20 years ago
|
||
Is anybody still seeing this? If so, please note here and use e.g. the freeware tool "Filemon" from Sysinternals to look what disk activity is occurring. For me (1.6 on Win2k, about 800kB bookmarks files, Athlon 2600+) this works absolutely, no noticable delay - and far from what would be 12 seconds on a slower machine.
Comment 16•20 years ago
|
||
See my Comment #13 above, it looks like it was related to that bug after all: personally I don't have this problem anymore.
Comment 17•20 years ago
|
||
-> WFM (comment #16, no answer from others)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•