Window & chrome redraw, black & white image, and cache problem



18 years ago
5 years ago


(Reporter: schapel, Unassigned)



Firefox Tracking Flags

(Not tracked)



(2 attachments)



18 years ago
Usually after a few hours of browsing with Mozilla on my laptop, Mozilla windows
start acting strangely. The main problem is that some or all areas stop being
refreshed or redrawn when the content change or when the window is uncovered.
For example, sometimes most of the chrome disappears, but reappears when I move
the mouse over it. Sometimes the whole window stops redrawing, and when I go to
a new page I must scroll down the page or use the mouse to select text on the
page to see it. Often when this happens, images start being drawn in
black-and-white -- not just greyscale but literally just extremely high contrast
with black or white pixels only. I will try to attach some screenshots the next
time this happens.

When Mozilla starts acting like I've described, I can go to
File|Preferences...|Advanced|Cache to clear the memory cache. Usually, this
fixes all the behavior I've described. This fix often works a few times, then
stops working. Then, I must restart the computer to fix the problem. It seems
like Mozilla's memory cache gets corrupted and clearing the cache can usually
fix the problem.

I've had this problem with builds from about the past two months, up to and
including build 2002032203. This problem happens only with Mozilla and it's the
only major problem I've been having (with Mozilla or any other program on my
laptop) recently apart from rare crashes. My laptop is the only computer I've
used during this time, so I can't say that I have or haven't had the problem on
any other computer.

Comment 1

17 years ago
Here's a screenshot of the redraw problem I took last week. For some reason,
the screenshot is black & white. I tried to get another screenshot, but I
haven't experienced the problem since, until I tried 1.0 Release Candidate 1.
Perhaps the bug was fixed on the trunk but not on the branch.

Comment 2

17 years ago
Sounds like a GDI problem. I've seen this in various other applications, usually
when I'm screwing around with GDI in VC++ or VB. I think this has to do with
grabbing handles to the desktop and such, and not releasing them properly, which
ends up causing DC's then created to end up as black-and-white.

Oh well, just speculation - this sure is weird. :)

Comment 3

17 years ago
Whatever the problem is, it happened again with trunk builds 2002042303 and
2002042603 recently. If it is a GDI problem, what Component should this bug be
assigned to?

Comment 4

17 years ago
Bug 130746, bug 137410 and bug 139538 seem to describe the same problem, also
with Windows 98.

The comments in those bugs ask the user to reinstall Mozilla (including creating
a new profile), and list the graphics card used. I have reinstalled Mozilla
twice, and I still experience the problem with the latest nightly trunk builds.
I'm using a Dell Inspiron 3500 with a factory installed NeoMagic MagicMedia 256AV.

Comment 5

17 years ago
I also see this on Win98 with the 2002051008 build, even after a clean install.
I use a Diamond Viper V770Ultra card.  I don't get the chrome turning B/W like
the screenshot in this bug, but it does sporadically happen to page graphics.  I
usually see the "refusing to redraw" problem begin when opening a new tab, if
that helps.

Comment 6

17 years ago
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true

Comment 7

17 years ago
> I don't get the chrome turning B/W like the screenshot in this bug...

The chrome wasn't B/W when I took the screenshot... this bug also causes captured
screenshots to become all B/W. In bug 130746, the reporter took "screenshots"
with a videocam! ;-)

Comment 8

17 years ago
Updating summary to match similar bugs so this one can be found more easily, and
nominating for Mozilla 1.1
Keywords: mozilla1.1
Summary: Memory cache and window redraw or refresh problem → Window & chrome redraw, black & white image, and cache problem

Comment 9

17 years ago
Since I've also been bitten by this bug on Win98SE using a Geforce 2 graphics
card, here's how I was able to reproduce it:

1. Go to

2. Click on the link to the last message, "Lizenzbruch"

3. Position the mouse cursor over "Nächster" (next) in the navigation bar right
above "Lizenzbruch"

4. Start clicking away on the same spot - upon clicking the link, wait till the
status bar shows that the next page has begun loading, then start hammering on
the left mouse button to immediately click the next link as soon as it appears

5. Repeat step 4 50-100 times, then try maximising the window or hitting F11 to
go to full screen mode, or just resize the window

Expected result:

Mozilla should redraw the whole chrome upon resizing

Actual result:

In most cases, only the page contents and the favicon will be redrawn over what
other windows were on the screen

(I'd love to provide a screenshot, but as mentioned before, as soon as the bug
kicks in, taking a screenshot is getting problematic... :( )
*** Bug 137410 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
*** Bug 130746 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
imagelib or widgets.
Assignee: gordon → dcone
Component: Networking: Cache → XP Toolkit/Widgets
QA Contact: tever → timeless

Comment 13

17 years ago
I've got a GeForce2 card as well, the Ti version, and have regularly come across
this bug too. In playing around I found that the screen resolution and color bit
depth had a hand to play in what was happening.

To reliably reproduce this bug on at least a Win98 system, set the screen
resolution to 1280x1024 and the bit-depth to 32-bit color. 

Load up a page and with the window unmaximised (normal) with the window to the
top left. The left and top borders should be near the top left of the screen,
while the right and bottom border should be at the halfway mark of the
screen.This position is unimportant so far as the results go, but it does make
observin the results of the test a lot easier.

 With the top left near the edge of the screen, drag the bottom right corner
around to different places. You will observe that the chrome breaks in relation
to how big the window is. With a half-height window it doesn't appear to break.
When it's 3/4 of the screen height it breaks, and when the window is the full
height of the screen it breaks at about half the width.

If you are increasing the window size to the right you will see the mozilla icon
on the toolbar stop moving.

If you are increasing the window size in a downward direction you will see the
status bar lose its information.

There appears to be a correlation in how many resources are required to show the
information for the window. A tall window breaks much more readily than a narrow
one when they have their width adjusted.

Comment 14

17 years ago
I hadn't noticed this for several builds, but I see it again in Build
2002092608, win98.  I also have a GeForce2, and I get exactly the behavior that
Paul mentions - works in 16 bit, chrome and content draw loses it in 32bit above
a certain window size. 

Comment 15

17 years ago
Again, hadn't seen this (or at least it was a minimal effect, like just a few
buttons) for several builds.  Just loaded 2002101612 and it is back in full
action, causing the entire window to go transparent/unresponsive, even on first
load at the stored default size/position.  Again, this is in 32 bit mode, and
only above a certain window size.  Manually scrolling forces a redraw, as does
placing another window in front and then moving it.

Why did this come back?


17 years ago
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha

Comment 16

17 years ago
Installed the latest Nvidia generic drivers - the size of the window no longer
seems to matter, and it takes a lot longer to corrupt now, but after many
windows and many pages, the chrome and page images eventually start corrupting
by overwriting new images on top of old.

Comment 17

17 years ago
Bug 153864 might be a dupe or related to this bug.

Comment 18

17 years ago
Continuing from bug 153864:
Yes this is the bug I'm seeing, with 2003012417. I too have a NVidia Geforce 2
card, running in 1152x864 32-bit mode, and see the chrome refresh problems. Yet
only with starting with 2003012417 (I updated that from something around
20030110ish), I've never had any problems before.

Comment 19

17 years ago
This reappeared lately.  It improves running 16 bit color vs 32 bit, and perhaps
is postponed by turning off some of the win98 gewgaws (animate window resize,
show window contents while dragging), but it's back in 2003020204 and several
previous builds over the past few weeks.

win98se, geforce2 MX, recent drivers.

Comment 20

16 years ago
This is still present in 1.3 final (20030312) and has become worse since 1.2.1
i.e. the problem happens after much less time.

OS: Win 98 SE
Graphics Card: NVIDIA Vanta PCI 32MB, BIOS
Video Driver Version: Creative
Screen res: 1600x1200
Bit Depth: 32bit
Mozilla window size: 800x1200


16 years ago
Keywords: nsbeta1

Comment 21

16 years ago
Is it me or is it getting worse? I'm on 2003050108, and opening 5-6 tabs and
surfing around for ~10mins (!), I start seeing the effects mentioned by others
in this bug. It affects all mozilla windows, not only the browser window.

Can someone change the target milestone and perhaps up the severity?

Comment 22

16 years ago
Finally got a non-black-and-white image of the bug i'm seeing. Is this similar
to what others are seeing?
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-

Comment 24

16 years ago
> Is it me or is it getting worse?

I'm seeing some sort of other problem with Mozilla recently. Mozilla and other
programs report "Out of Memory" errors, and fonts and graphics get corrupted in
all programs. Quitting programs temporarily makes the symptoms go away. This new
problem seems to be quite different from this bug.

Comment 25

16 years ago
I've had the problem shown in Mark's screenshot
It's appeared in both the browser and mail client

I think it happens when i have quite a lot of tabs open and having other
non-mozilla apps open may have contributed so it may be memory related.
I think the last two times this happened, it was actually triggered when I tried
to access a menu in either the browser or mail client. Then areas would fail to
redraw as described in the original bug description and i'd get those black
lines round things.

Im using Mozilla v1.4b under win98
I dont think i experienced this with previous milestone builds

Comment 26

16 years ago
If you can get a color screenshot, if the problem never goes away when you clear
the cache, and if you can get the problem to go away by closing other open
applications, it likely isn't this bug. The "out of memory" bug described above
has been fixed in the latest nightlies, both on the trunk and the 1.4 branch.


16 years ago
Flags: blocking1.4?
Keywords: mozilla1.1

Comment 27

16 years ago
dcone is no longer working on this.
any other willing to take this?
Keywords: topembed

Comment 28

16 years ago
The last comments seem to refer to bug 204374 . Is this a dupe ?

Comment 29

16 years ago
> The last comments seem to refer to bug 204374 . Is this a dupe ?

I don't think so. The symptoms of the two bugs seem completely distinct to me. I
still do experience bug 204374 -- this might have been the cause for the "Out of
Memory" errors I was getting, but I no longer get those error messages, just the
font and graphics corruption. But unlike this bug, that bug goes away when I
close other applications.

Comment 30

16 years ago
The bug in action with latest stable 1.4 (win32) at:

Windows XP SP1 with loads of applications running. If I end most of them, 
Mozilla will work fine for a while but then after 2-3 hours of heavy surfing 
and 10-15 tabs open I have to restart it.
Flags: blocking1.4?

Comment 31

16 years ago
Assignee: dcone → jdunn
Target Milestone: mozilla1.3alpha → ---

Comment 32

16 years ago
The quick test to see if this is a dup of bug 204374
-have only one window (no extra tabs) open
-type in and goto the url  "about:blank"
-clear cache (Edit->Preferences->Advanced->Cache => Clear Cache)
-type in "about:config", scroll down to "browser.cache.memory.enable"
 click on it, change "true" to "false".

surf... do you still see the problem? if not then I am 99.9% sure
this is a dup of but 204374

Comment 33

16 years ago
Yes, it's still there. I tried opening a page with about 100 1280x1024 JPEG
images and the problem still persists.

Comment 34

16 years ago
I am getting the same redraw problem discussed in this thread:
Win98, physical memory: 654Mb, resources: 27%free
ATI Radeon7500 video card, BIOS: 2001/09/28
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624

I'll try upgrading the BIOS to see if that helps.

Comment 35

16 years ago
from comment #33, if you open 100 1k by 1k images you may run into
this.  BTW I have a patch being looked at in bug 205893, awaiting review.

just as one more test, can you bring up Resource Meter after you have
loaded the 100 images and the screen starts to flake out and tell
me the % you are seeing

To run Resource Meter:
Start->Programs->Accessories->Systems Tools->Resource Meter
This will add an icon to your active programs, click on it and let 
me know what your % free of each of the 3 things are.  Thanks

Comment 36

16 years ago
Sorry, it's Windows XP and there is no resource meter there. I could check
User/GDI objects in taskmgr if it would help?

Comment 37

14 years ago
(In reply to comment #33)
> Yes, it's still there. I tried opening a page with about 100 1280x1024 JPEG
> images and the problem still persists.

Can you give some steps to reproduce? I just created a page with 100 1280x1024 JPEG images, and when I viewed it I saw no problems using SeaMonkey 1.0. It's currently using about 300 GDI objects, which doesn't seem excessive.

Comment 38

14 years ago
Bug 284978 looks like a similar bug relating to GDI usage and repainting.
Assignee: jdunn → win32
Component: XP Toolkit/Widgets → GFX: Win32
QA Contact: timeless → ian


11 years ago
Closed: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.