225977 - Painting problems with page that has large number of images - resource leak?

Status: VERIFIED DUPLICATE of bug 213391

(Core Graveyard :: GFX: Win32, defect)

Description

[WD]

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.

Comment 1

[Alex G.]

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

Comment 2

[WD]

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)

Comment 3

[WD]

*** Bug 226435 has been marked as a duplicate of this bug. ***

Comment 4

[WD]

*** Bug 227245 has been marked as a duplicate of this bug. ***

Comment 5

[WD]

Another URL:
http://home.t-online.de/home/gunther.mayer/bttv/bttv-gallery.html

Comment 6

[Bogdan Stroe]

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 

Comment 7

[James Hamilton]

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.

Comment 8

[Asa Dotzler [:asa]]

*** Bug 178105 has been marked as a duplicate of this bug. ***

Comment 9

[R.K.Aa.]

*** Bug 233873 has been marked as a duplicate of this bug. ***

Comment 10

[R.K.Aa.]

there seems to be dups of this also in bug 193011

Comment 11

[Dave Dyer]

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).

Comment 12

[Daniel de Wildt]

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 ***

Comment 13

[WD]

V. Dupe.
The patch for bug 213391 fixes this problem.