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.
*** 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]
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?
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
*** 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 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)
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 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
*** Bug 183007 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.