User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:188.8.131.52) Gecko/20081201 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/2009032609 Firefox/3.0.8 Sorry that this is not going to be a very precise bug report, and possibly hard to replicate, but it looks as if it is unreported thus far. This probably pertains only to windows 2000 (sp4). If I open enough tabs in enough windows, when firefox tries to render the final window, a nearly total rendering failure occurs. What I mean by this is that if a window needs to be redrawn, either because it was minimized or obscured, almost nothing is rendered in any window. A few icons (such as folder symbols in bookmarks sidebar) are drawn, but no text is drawn. Components which are drawn on mouseover, however, do get drawn when the mouse passes over. If a window is restored from being minimized, only the graphic components of the decoration are drawn, not, e.g. the bar where it says "File" ... "Help". This problem did not occur with the last released stable version of Firefox 2, drawing the exact same windows. (18.104.22.168). The total amount of memory being used when this problem occurs with FF 22.214.171.124 is about 300MB, on a machine with 1GB of physical memory. FF126.96.36.199 would use about 500BM of memory for the same set of url's. I am currently generating this problem when I open the 11th window, with something like 70 - 100 total tabs open. I see this problem reliably when I stress FF3 this way. Problem also occurred with at least 2 prior release versions of FF3. Also, I can tell you that at the moment FF is using 914 USER objects and 1958 GDI objects. I have seen other resource shortage failures in win2k, and that is what this smells like to me. I don't think it's a GDI shortage, because other applications' windows perform just fine. Reproducible: Always Steps to Reproduce: 1.open FF with no add-ons 2.open a multi-url bookmark folder in tabs, with say 8 tabs. (I will attach a bookmark snippet for exact urls and folder structure.) 3.create a new window (e.g. with ctrl-N) 4.goto 2. 5.repeat steps 2-3 opening 11 windows total. Actual Results: Once the 11th window tries to render enough stuff, most rendering disappears and no normal method refreshes it in any window. Sometimes FF also hangs, or appears to hang. Expected Results: Normal rendering of all windows. I will attach a piece of bookmarks.html which contains a folder with subfolders which causes the problem on my machine. (This is a bookmark folder which renders fine on 188.8.131.52.)
Created attachment 370313 [details] bookmarks json file. folder 20090330 contains folders to put into tabs of successive windows. Fails at window 9. (starting counting with '1') This attachment contains bookmarks which reliably generate the lossage for me. Folder '20090330' contains several subfolders. Each subfolder contains several bookmarks. For each subfolder, in order, open all the bookmarks in tabs in a new window. the 9th window causes the failure for me. (There are more than 9 subfolders, but opening all the url's in tabs in the 9th folder is when the failure occurs. I earlier said 11 windows, but I had some minor windows open at the time that are unnecessary to cause the failure.) I have not checked whether the failure will occur with fewer tabs in the 9th window. I also note that in safe mode, the failure is similar but not exactly the same, as somewhat more rendering seems to happen, although it is still true that no text is rendered in the bookmarks sidebar, and text is not rendered in toolbars. The amount of rendering in the main display pane is somewhat variable, but always screwed up. Note that I have observed this problem with a variety of bookmark sets, so I very much doubt it is related to any particular website.
Maybe I should emphasize that the attachment is a .json file which can be loaded via the bookmarks>restore feature. Also I doubt this will be reproducible on a machine not running windows 2000 sp4. And, it may well not occur at this point if you have fewer processes going, or have more memory than me (1GB). I currently have 75 processes, using about 994MB of memory. There is about 1.5GB of swap space available. In addition, since I would guess this is an issue with something like catching window messages, I fear it may depend on just what other window resources are being used by other applications. However, running FF184.108.40.206 in the [almost] identical environment does not generate the problem. "Almost" because I have to run FF2 and FF3 sequentially, not concurrently to avoid massive swapping.
Created attachment 370320 [details] screen shot of a single FF window after lossage Here's what a window looks like after the lossage takes place. Note the desktop portion will translate with window when moved. Also, note that some graphic elements render ok.
probably related to ms-windows resource shortage. Version 3 changed how it uses gdi objects. And other things have changed even more recently. ref Bug 445385 comment 7. what results do you get with version 3.6?
Whiteboard: [closeme 2010-08-15]
(In reply to comment #4) > > what results do you get with version 3.6? I've upgraded all my currently functional machines to win xp, so although I don't see this bug with 3.6, that means nothing. Win 2k had much more severe resource limits, as I understand it. I may be able to look into this again some time in the future when I have a working win 2k machine again.
Thanks for the update. I should have mentinoed - don't waste your time testing win2k - no one will care (including me). yeah, it's supported, but as a practical matter there'd be very few users. I've got a win2k box but stopped testing win2k only bugs a year ago. if you can't reproduce on a newer version then this bug should be closed out IMO.
No reply, INCOMPLETE. Please retest with Firefox 3.6.8 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.