User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028 *** Note: The URL for this bug is NOT SAFE FOR WORK *** The URL for this bug has a page that has over 100 images in an XHTML web page. When I visit the page, mozilla no longer properly paints properly. (similar to bug 204374 , but I couldn't see any abnormal GDI usage myself) Reproducible: Always Steps to Reproduce: 1.Go to http://www.boobdex.com/recent/NOV/11172003i.html (NSFW) 2.click on another tab 3. Actual Results: The content area for the new tab isn't painted properly. (artifacts of original page). Also, the other areas of Mozilla such as menus, etc. do not paint right either. Expected Results: no problems. I have tried the workaround listed in bug 204374 (setting memory cache), but that has no effect whatsoever. The GDI Resource tool listed in that bug shows no abnormal GDI usage when that page is open either. Mozilla must be closed for it to function properly again.
Providing a better URL (Safe for work, etc.): http://www.cs.virginia.edu/~robins/family_gallery.html This website has over 400 pictures. When opened in mozilla, the GUI refuses to properly redraw and only by closing the tab can mozilla be used. (All other tabs are not drawn correctly with this url opened in any tab.) It is impossible to scroll once the pictures are all displayed. This URL will open properly in IE, but not mozilla. IE will increase the memory usage to 200Megs when opening this URL while mozilla stops at about 70Megs. Reproducible: Always on Windows Tested on: Windows XP Tested with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030804 Works on: Linux (Gentoo) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031119
Changing URL for bug to a SFW one. I've compared GDI usage for IE and Mozilla/Firebird and what's interesting here is that IE actually uses *more* resources than Mozilla, yet it causes no painting problems. Total DC Region Bitmap Pallette Font Brush Other Mozilla: 301 3 24 220 5 12 37 0 IE: 558 23 4 487 3 22 19 0 The other thing I noticed is that as the page is loading, most other apps seem to work fine, painting-wise. (Eudora, AIM, Windows Explorer, etc...). But the programs that are immediately affected are Thunderbird and Firebird (Or Thunderbird and Mozilla if I'm loading the page in Firebird)
*** Bug 226435 has been marked as a duplicate of this bug. ***
*** Bug 227245 has been marked as a duplicate of this bug. ***
I also tested with this web page (http://www.jasonpan.com/china/) reported in bug 211377 (probably a duplicate). It works fine for a while, but the system eventually becomes slow, and the windows are not repainted properly. However, if I close that window, Mozilla is working fine again, except that the memory doesn't come down to the previous levels (the difference is about 40MB). I guess it's a memory leak somewhere. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040117
I'm getting the same behavior in Windows Server 2003 with 2.6gb of memory (74200 used by Mozilla, not a lot really). URL (somethingawful account required): http://forums.somethingawful.com/showthread.php?s=&threadid=889925&pagenumber=2 Almost any big image thread will trigger the behavior. Note that it is NOT impossible to scroll. It is only impossible to scroll using the keyboard (arrows or pgup/pgdown). Scrolling still works when using the mouse to drag the scrollbar or using the scrollwheel on the mouse.
*** Bug 178105 has been marked as a duplicate of this bug. ***
*** Bug 233873 has been marked as a duplicate of this bug. ***
there seems to be dups of this also in bug 193011
This bug is probably the same as bug 204374 A page which shows this bug immediately in mozilla 1.6 is http://www.scat.demon.co.uk/zertz/strategy.htm In this case, scrolling with the mouse/scrollbar doesn't work either. AND note that it works fine with mozilla 1.3.1 (which consequenly seems destined to be my default browser forever).
I think this bug is a dup of bug 213391. Each image is stored in the cache even if the is cache is already filled. None of the already loaded images could be removed from the because they are in use by the page self. You can check this by entering about:cache in an other tab after (or when) loading the page. In bug 204374 comment 340 I mentioned that the cache workaround will not work in some cases (like this one). *** This bug has been marked as a duplicate of 213391 *** *** This bug has been marked as a duplicate of 213391 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
V. Dupe. The patch for bug 213391 fixes this problem.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.