From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.5+) Gecko/20011010 BuildID: 2001101003 One of the most noticable speed problems now seems to show up when you close a page. When one closes a page, the window disappears very quicky, but mozilla windows behind it don't notice or update for a bit. The result is, even though the page went away nicely, your other mozilla pages are not redrawn and are full of junk for a bit. Reproducible: Always Steps to Reproduce: 1.open two mozilla pages (or mailnews) 2.fill with content 3.bring one page in front of another, then close it Actual Results: Although the closed page goes away quickly, the pages behond it don't update, so they're full of junk from the closed page and the perception is bad page close performance. Expected Results: The behind pages should redraw or whatever more quickly.

Looks like a dupe of bug 84920.

yes, I suppose. However, hyatt asked that this bug be filed on him, so let's let him nuke it, if he wants (or not).

This is number 3 on our performance Hit Parade. P1, adding perf keyword.

The bug has little to do with closing windows -- it's the redraw speed of the windows in general.

I don't think so. It seems much worse when you close a window than when you simply drag another window out of the way to uncover it.

I have looked into this and almost reported it before finding the bug listed here already. The problem seems to be, at least for me, that Mozilla writes or reads the hard disk continuously after closing a Mozilla window which is on top of another window. The wait time seems to increase as the window sizes increase. For popups, I generally wait about 3 seconds for the window to close and for full screen browsers, it takes about eight seconds of continuous disk thrashing. I haven't tested this on my FreeBSD system, but it does not appear to happen on my mother's Linux system. My config: Windows 2000 Maxtor 7200RPM IDE drive 512MB RAM (Mozilla uses about 27MB usually) with 350MB free Mozilla 0.9.9 release, binary install from mozilla.org

I also have Win2000 and same problem. Only happens when I close a Mozilla window. Does not happen when I close a tab, or when I minimize a window. Closing a Mozilla window, all other Mozilla windows are hanging for a couple of seconds. I have an 800Mhz PIII. The problem is reproducible about 90% of the time. As a workaround, I am now always trying to open new tabs instead of new windows. Or use IE :(.

BTW, shouldn't the summary of this bug be "_slow_ refresh on window close"? The way it is, its difficult to find if searching for "slow window close".

I am _begging_ to get this fixed for the 1.3 version. If it is not fixed my company will have to continue using Netscape 4.76 on Red Hat 6.x for mail. Can you believe it? We are in the midst of migrating to Red Hat 8 and have really hit a wall on this. I believe that this bug may be the same or is very closely related to: Bug 84920 Bug 89919 ?? maybe Bug 104176 Bug 103241 Bug 136230 Bug 163264 I am reporting the same message to these other bug nubmers. This bug is extremely serious to those users that it affects and makes Mozilla -- ESPECIALLY THE MAIL which does constant opening and closing of windows -- unusuable in a business/production environment. Several reporters have stated this, but so far -- after more than 18 months -- to no effect. I believe that this bug has not received the proper attention because: 1) It was spread over many reports that used varying terminology. 2) It was assigned to various people, one of whom appears to have been oblivious about it before he become employed elsewhere. Nobody seems to have realized that all these reports are about the same thing. 3) ***** The bug is less noticable on faster or dedicated systems that developers and engineers are more likely to use. However, for a business user working over a busy network, connecting to a busy server, it is a PRODUCTIVITY KILLER. The distillation of all the reports is: PROBLEM: A) Any screen redrawing resulting from window opening, closing, moving, minimizing/maximizing, or resizing is EXTREMELY SLOW, particularly when multiple Mozilla windows are open. Redrawing is also very slow when focus is changed from one mail folder to another or when the user right clicks on a mail folder to get a context menu. For example, when I move THIS browser window, I momentarily see FIVE (5) duplicates of this window and I can count four seconds before all the screen redrawing is done. Resizing is even slower -- it take about an 8-count before the screen is redrawn. Closing this window also takes about an 8-count before the screen is fully redrawn. Minimizing this window is quite bizzare; there are about fifteen (15) momentary black-outlined rectangles getting smaller and smaller as it minimizes; a 5-count before all redrawing is complete. B) If you are working only in one screen typing like I am now, this is not a big deal. However, _MAIL_ users are constantly opening message windows, changing focus between IMAP folders, etc., etc. As I have spent a couple days test using the mail, I have made many mistakes because I thought all the redrawing was done when it was not. As a result, messages have been dragged to the wrong folders, folders have been expanded or unexpanded when I was trying to do the opposite, etc. (I have tons of experience using NS 4.76 doing the exact same work and have never had any of these kinds of problems.) This is a PRODUCTIVITY KILLER for mail users. C) Reporters have reported this on: Linux X11 Linux (ver not stated) on a PC Windows 95 PC Windows NT4 PC Windows NT 5.1 Windows 2000 OS X on iMac & G4 (but maybe only 10.2 or higher??) Sun OS (version ?) Solaris 2.8 D) All reporters seem to be reporting on reasonably (to very) fast machines with decent to excellent amounts of RAM. E) Several reporters have clearly stated that it is "virtually unusable" or otherwise not useable in a business environment. I must agree! MY EXPERIENCE: 1) This Mozilla is running on a Red Hat 8 server to which we are migrating. Our migration is essentially stalled until this issue is addressed. I cannot believe that I am going to have to keep running a Red Hat 6.x server to provide Netscape 4.76 email to my staff! Red Hat 8.0 with kernel 2.4.18-18.8.0 and all but the latest (i.e. last two weeks) updates via RH up2date. UW IMAP vers 2001a release 15 from Red Hat supplied RPMs (from RH install CD). Mozilla 1.2.1 (Xft build) from Mozilla RPMs Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 2) When we first saw the problem, we assumed that it was an X problem, so we tested per the below. The workstations are Windows 95 PCs (we hope to be Microsoft free by the end of 2003!) running X windowing software to provide X access to the Linux servers. *** NOTE THAT THIS X WINDOWING (and 10 mb network in general) IS PROBABLY PROVIDING SOME OF THE DELAY THAT MAKES THIS BUG MORE OBVIOUS. (It is sort of like testing an application over a 28.8 kb modem to see what is really going on.) HOWEVER, _ALL_, I REPEAT _ALL_ OF OUR OTHER RH 6.X AND RH 8 APPLICATIONS DO _NOT_ HAVE ANY OF THESE REDRAW SPEED ISSUES, EVEN WHEN THE NETWORK IS UNDER HEAVY LOAD. a) Tested through SCO's PC XVISION 7.32 running on Windows 95 running Mozilla running on our RH 8 server. Mozilla is the only application that shows any redraw speed problems. This is our oldest Xwindowing software. The PCs tested were 300 to 400 MHZ machines with 256 to 512 MB of RAM. b) Tested through CYGWIN XFREE86 4.2 (the latest production release) running on Windows 95 running Mozilla running on our RH 8 server. Mozilla is the only application that shows any redraw speed problems. On this newer Xwindowing software, the redraw problem was perhaps 20% less (20% faster) than on the XVISION. The PC tested with Cygwin (specifically installed for THIS test) is a 400 MHZ machine with 512 MB of RAM. c) Tested directly on our Red Hat 8 server console (i.e. no network, PC, or windowing software to slow things down) running DUAL 1 GB processors with 3 (three) _GB_ of RAM. Redraw is noticable, but would not bother anybody. When moving one Mozilla browswer window around on top of another, I get momentary duplication of the chrome -- about five to six copies of the window. By comparison, similar window movements of other application windows on this machine do NOT show this delay -- for other applications, redraw is instantaneous. However, as I said, it is perfectly usable -- BUT not every staff member (none, in fact) can use the server as a workstation! Please help! Jay

This problem drove me insane, it appeared to be getting worse with time. However, for me it appeared only when I closed a window - minimizing or switching between Mozilla windows did not cause this long delay. I then completely uninstalled Mozilla and erased my Mozilla profile (removed the Mozilla folder from the "Documents and Settings" folder - backing up just the Mail folder and the bookmarks file). After I did a fresh install of Mozilla, creating a new profile folder, the problem went away. I still occasionaly see a short delay in closing windows, but its reasonable.

Why was I removed from cc (I have re-added assuming that this was an error)? I'm sorry if I did something wrong, but does removing me fix the problem or make the product better? I am a real business user in charge of trying to move our operations to Mozilla. If you want me to do something different, please advise. Thank you. Jay

Does Hyatt works anymore on mozilla? I belive hi's now working on KHTML (for Apple's Safari browser)... Should we reassign all his bugs to someone else? I'd like to hear comments from Hyatt itself on this. Tnx.

Nav triage team: nsbeta1-

aha, please don't remove that keyword.

Somehow, I don't think this one's gonna get fixed.

I am (still!!!) Mozilla 1.7.3 on (still!!!) RedHat 8. I do not see this problem in my current environment. Our current environment is not much different than when this was reported, however, something must have changed because it is no longer an issue for us. I suspect that the change relates to upgraded/better xwindowing, newer RH8 kernel, faster network, or some other related-but-not-obvious software upgrade that affects our xwindowing performance. Jay

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112605 Minefield/3.0b2pre