loading lots of images makes moz forget to repaint everything

VERIFIED DUPLICATE of bug 204374

Status

Core Graveyard
GFX
P2
major
VERIFIED DUPLICATE of bug 204374
15 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Assigned: Kevin McCluskey (gone))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
Steps to reproduce:
1. Drag the "linked images" bookmarklet from
http://www.squarefree.com/bookmarklets/pagelinks.html to your bookmarks toolbar.
2. Go to http://pantransit.reptiles.org/images/nsorted/anime/azumanga-daioh/.
3. Use the linked images bookmarklet.
4. Wait for all the images to load into the new window.  If you want, read them
while they load.
5. Close the new window.
6. Use the linked images bookmarklet again, letting Mozilla load the images from
the cache.

Result: Mozilla gets into a state where it forgets to draw many things.  This
affects all Mozilla windows.

Not drawn:
  loading a new page
  switching from another application that covered the window
  scrolling a page at a time (click in scrollbar elevator, pgdn)
Drawn:
  chrome buttons, but only when I mouse over them
  scrolling in small increments (mouse wheel, arrow keys, drag scrollbar thumb)

I hit this bug a lot while surfing porn and using the "linked images"
bookmarklet, but this is the first time I've been able to reproduce the bug. 
(The URL above is not porn.)  Closing the window that contains all the images
usually (always?) makes the problem go away.

I suspect that something is going wrong at the OS level.  If I trigger this bug
using Phoenix, then Mozilla windows also forget to redraw.  But other apps
(winamp, mIRC, notepad, IE) don't have any trouble remembering to draw.

I'm using Windows XP.  Display Properties > Advanced > Adapter reports that I am
using "16MB ATI Rage 128 Ultra", which has chip type "RAGE128 PRO II, (AGP 4X/PCI)".

Related: bug 157256, "Repainting of most widgets is not happening under Win98
after a period of time".  The symptoms are the same, but bug 157256 doesn't have
steps to reproduce.

Reproducibility: 0/2 when uncached, 5/5 when cached.  Tested in both Phoenix 0.5
and Mozilla 12/07.
I also see this, using build 2002120604 on Windows 2000, with a GeForce2Go.

It also happens to me when browsing lots of images (e.g. when surfing porn), and
specifically happens a lot more when the images are cached (e.g. when surfing
freenet porn). It affects all open Mozilla windows at the same time. Closing
tabs after a while can stop it happening, but it can just start up again as well
(presumably when the more cached images are viewed?).

Basically, the windows stop painting. Reflow has no effect. Menus don't render.
Scrolling with the page up/down keys does nothing. Slowly moving the scrollbar
(if you can hit it) repaints newly exposed bits of the page, but scrolling fast
has no visible effect. Hovering over elements of the UI that have :hover rules
causes them to repaint. Dragging the window slowly off-screen and back causes
exposed bits of the window to repaint. Dragging another window over the top does
not. Other applications are totally unaffected.
(Reporter)

Comment 2

15 years ago
*** Bug 187722 has been marked as a duplicate of this bug. ***

Comment 3

15 years ago
For me, this is reproducible 100% of the time using the procedure described (and
many others, unfortunately).

I am using: Windows 2000 Server, [Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.2.1) Gecko/20021130]
(Assignee)

Updated

15 years ago
Priority: -- → P2
Target Milestone: --- → Future
This is really disconcerting. I haven't heard any non-Windows reports of this
happening, so my guess is that we are simply leaking some system object,
probably GDI, when we view images, probably specifically cached ones.

Anyone have any ideas?

Comment 5

15 years ago
Confirming exactly the same behaviour on linux 2003012722. Something similar
happens if you open a lot of image links in tabs. Some of them stay grey and
can't be closed anymore. Weird. Happend to me for example when serching for
train bridges with googles image search and opening the picturelinks in new tabs.
OS: Windows XP → All

Comment 6

15 years ago
*** Bug 192362 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
*** Bug 187526 has been marked as a duplicate of this bug. ***
Confirmed in moz 1.3a, and 1.0.2.

I attempted to take a screenshot using printscreen and MSPaint.  Earlier today
it was giving me an error, now it did what MS Word did earlier: give me an ugly
black & white image.

http://ctho9305.res.cmu.edu/pics/moz.PNG (the left part of the browser is
showing http://forums.anandtech.com/messageview.cfm?catid=38&threadid=971379,
the rest is showing this page.  I dragged winamp over the part showing anandtech
to get it to redraw itself)

Comment 9

15 years ago
Possibly a dupe of bug 133132.

Updated

14 years ago
Flags: blocking1.4?

Comment 10

14 years ago
With my patch for bug 205893 I still see the problem, UNLESS
I set my disk cache to 150Mb (100Mb doesn't work).  Please don't
ask me why this helps, it just does.  I also tried just
not using GDI resources for images (in nsImageWin :: Optimize
just return NS_OK;) and the problem goes away (this is with 
my default 50Mb cache size).

Comment 11

14 years ago
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?

Comment 12

14 years ago
Jim, do you see this problem under NT and 9x with patch 127547 , or just under
9x?  9x does not have a maximum number of bitmaps, rather a maximum memory
capacity the bitmaps must fit into. Might it be the case that there are less
than BITMAP_CACHE_SIZE handled bitmaps, but their total size is greater than the
GDI capacity, so the GDI is full but the cache isn't getting emptied?

Presumably OS should be set to 'windows 95' for this bug?

Comment 13

14 years ago
No this bug, I see on both 98 & win2000 with and without patch 127547 (bug 205893).

Comment 14

14 years ago
This now appears to be fixed based on the patch for bug 216430
(which fixed the regression caused by bug 205893
(Reporter)

Comment 15

14 years ago
I haven't been hitting this bug lately.  The URL in comment 0 has changed and no
longer screws up Phoenix 0.5, so I can't be sure that this bug was fixed.  I
think it would be reasonable to mark this as a dup of bug 205893.

Comment 16

14 years ago
It still exists with firebird 0.7+ win98. I think it has to do with bug 204374,
or at least some other form of memory leak.

Comment 17

14 years ago
I am still seeing this with 1.5 and windows 2003. Very very annoying.

Comment 18

14 years ago
*** Bug 226234 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
*** Bug 228436 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 20

14 years ago
*** Bug 211455 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 21

14 years ago

*** This bug has been marked as a duplicate of 204374 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → VERIFIED

Comment 23

14 years ago
*** Bug 183007 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.