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
Result: Mozilla gets into a state where it forgets to draw many things. This
affects all Mozilla windows.
loading a new page
switching from another application that covered the window
scrolling a page at a time (click in scrollbar elevator, pgdn)
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.
*** Bug 187722 has been marked as a duplicate of this bug. ***
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]
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?
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.
*** Bug 192362 has been marked as a duplicate of this bug. ***
*** 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
the rest is showing this page. I dragged winamp over the part showing anandtech
to get it to redraw itself)
Possibly a dupe of bug 133132.
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).
mozilla1.4 shipped. unsetting blocking1.4 request.
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?
No this bug, I see on both 98 & win2000 with and without patch 127547 (bug 205893).
This now appears to be fixed based on the patch for bug 216430
(which fixed the regression caused by bug 205893
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.
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.
I am still seeing this with 1.5 and windows 2003. Very very annoying.
*** Bug 226234 has been marked as a duplicate of this bug. ***
*** Bug 228436 has been marked as a duplicate of this bug. ***
*** Bug 211455 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 204374 ***
*** Bug 183007 has been marked as a duplicate of this bug. ***