299252 - Problems with redraw of screen with Gecko/20050630

Status: VERIFIED FIXED

(Core Graveyard :: GFX: Win32, defect)

Description

[Michael Taeuber]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.9) Gecko/20050630 Firefox/1.0.5

After installing the nightly 2005-06-30-05-aviary1.0.1 I got problems with the 
screen redraw. After working a short while with Firefox e.g. the title bar of 
all windows is partly overwritten, I can wipe the icons from my desktop by 
moving around with the Firefox window. I can submit a screenshot to clarify the 
problem.
No problems with 2005-06-29-04-aviary1.0.1 and all predecessors

Reproducible: Always

Steps to Reproduce:
1. work with Firefox for some minutes
2.
3.

Actual Results:  
Problems with redraw

Expected Results:  
correct redraw

Comment 1

[Tracy Walker [:tracy]]

Yep, this is very ugly.  

Comment 2

[Michael Taeuber]

I tried to make a screenshot but W2k tells me that there is no memory available 
for the bitmap. 
The task manager tells me that there's plenty of memory left...

Comment 3

[Tracy Walker [:tracy]]

At first launch, scrolling and window resize performance has noticably
regressed.  As you continue to use Fx, things get worse.  Memory usage seems to
be increasing greater than normal. And eventually title bars disappear in
popups/dialogs and with window resizing. 

Once the title bar starts to disappear in Fx windows, it affects other apps
windows as well.  At this point, I also could not print from Fx with a generic
message that "An error occured during this operation". Printing worked during
the  first minutes of app use, before the redraw issue had become ugly.

Comment 4

[Jay Patel [:jay]]

This is probably the result of the image crash fix in bug 289864.  Dan checked
in some fixes that we were not completely sure would work, so we need to
investigate further.

Comment 5

[Jay Patel [:jay]]

Changing component, adding regression keyword, reassigning to dveditz, and
making blocker for 1.0.5/1.7.9/1.8b3.

Comment 6

[Daniel Veditz [:dveditz]]

Reassign back to me if all you want is a back out, but it's not something I'll
be able to fix.

Pav: is there something on trunk that the patches I checked in depend on that's
missing on the branches?

Comment 7

[Tracy Walker [:tracy]]

just for informations sake:  This is affecting Windows Tbird
2005-06-30-09-aviary1.0.1

Comment 8

[Bernard Alleysson]

I'm not so sure, but maybe the patch for bug 292051 is needed too

Comment 9

[Daniel Veditz [:dveditz]]

Pav says he's swamped, back to me to figure out which patches matter.

definitely want bug 292051 and bug 293586. Bug 282867, bug 285054, and possibly
bug 282867 are good bets. If we're cleaning things up bug 286236 and bug 289515.

Comment 10

[Daniel Veditz [:dveditz]]

Attachment: Patch that helps

This patch gets the branch gfx/src/windows looking like the current trunk, and
seems to help a bunch. Doesn't entirely solve the problem though.

Comment 11

[Daniel Veditz [:dveditz]]

I went ahead and checked into the ff1.0.1 branch so we can get some testing in
tomorrow. If reviewers reject it I'll back it out. I think this helps, but
doesn't eliminate the problem entirely.

Comment 12

[Michael Taeuber]

I'm sorry to say that the patches in nightly 2005-07-01-05-aviary1.0.1 don't
work for me. At my machine I can see no change in behaviour compared to
2005-06-30-05-aviary1.0.1

Comment 13

[Jay Patel [:jay]]

This is a branch only issue...clearing 1.8b3 flag.  Bug 284716 and others bugs
noted there fixed this on the trunk.

Comment 14

[Bob Clary [:bc] (inactive)]

It is hard for me to believe I haven't been hacked and that this bug is
responsible, but it seems to be that this bug has wide ranging problems in
windows. I see the title bar, window drawing issues as well but also corrupted
services which no longer run, a recycle bin that attempted to delete c:\windows,
and a machine that had become essentially useless until a hard shutdown. I am
running a full scan now, but if this bug is the cause it needs to be stomped asap. 

was using a cvs 1.0.1 branch build on winxpsp2 checked out at 4:19AM PT this
morning.

Comment 15

[Stuart Parmenter]

Attachment: fix

We were double creating tbits here due to one of the previous patches which
does the create prior to the if() for this else.  This brings it in line to the
trunk.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 187994 [details] [diff] [review]
fix

sr=dveditz
a=dveditz

Comment 17

[Stuart Parmenter]

checked in on 1.0.5 branch.  dveditz is going to check it in on the 1.7.9 branch.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 187994 [details] [diff] [review]
fix

r=biesi; the unshown context here (the if corresponding to this else) is:
if (nsnull == tbits)

Comment 19

[Daniel Veditz [:dveditz]]

Checked both patches into the 1.7 branch -- fixed in all broken places.

Comment 20

[Tracy Walker [:tracy]]

verified with Windows Fx 2005-07-05-04-aviary1.0.1

Comment 21

[Asa Dotzler [:asa]]

Comment on attachment 187924 [details] [diff] [review]
Patch that helps

1.0.5 and 1.7.9 have already shipped; unsetting approval requests.