625043 - MozTransform draws html elements over Firefox chrome if H/W acceleration enabled, as of 2010-10-22 nightly

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Ed Morley [:emorley]]

Attachment: Testcase

If hardware acceleration is enabled, MozTransform can draw html elements over Firefox chrome, since the 2010-10-22 nightly.

STR:
1) With hardware acceleration enabled, open attached testcase (was taken from bug 622585).
2) Watch element rotate.
3) Repeat steps 1-2 with hardware acceleration disabled & compare.

Expected:
- HTML element rotates without rendering over Firefox chrome.

Actual:
- If hardware acceleration enabled: element renders over chrome, if not: renders fine.
- See screenshot.

Occurs in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110111 Firefox/4.0b10pre ID:20110111030357.

Regression range...
Last good nightly: 2010-10-21 
First bad nightly: 2010-10-22

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4788083ce564&tochange=b6c9c4833613


# Graphics section of about:support #
Adapter Description: NVIDIA GeForce 6200 TurboCache(TM)
Vendor ID: 10de
Device ID: 0161
Adapter RAM: 64
Adapter Drivers: nvd3dumx,nvd3dum
Driver Version: 8.17.12.6099
Driver Date: 10-16-2010
Direct2D Enabled: false
DirectWrite Enabled: false
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 11 2011 04:14:27)
GPU Accelerated Windows: 1/1 Direct3D 9

Comment 1

[Ed Morley [:emorley]]

Attachment: Screenshot

Comment 2

[Ed Morley [:emorley]]

Suspect changesets in that range perhaps?

http://hg.mozilla.org/mozilla-central/rev/73f8c0079bc1 Bug 584494: Avoid creating intermediate surfaces in D3D9 layers. r=roc a=blocking-betaN

http://hg.mozilla.org/mozilla-central/rev/598cf02e1c4d Bug 606121. Clip the cached surface in basic layers so we draw only what we need to. r=roc a=joe

Comment 3

[Joe Drew (not getting mail)]

Hoo, that's a bad bug.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

WFM with D3D10. D3D9 only?

Comment 5

[Bas Schouten (:bas.schouten)]

Sounds like a problem in layers clipping.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I think this should be a hardblocker.  There are nasty spoofing possibilities here; if we had this bug on a stable branch we'd be fixing it there ASAP...

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Yeah, this definitely should be a hardblocker.

Comment 8

[Asa Dotzler [:asa]]

I don't see this on my Win 7 (d3d10) or my Win XP (d3d9) systems. Is this only d3d9 on Win 7?

Comment 9

[Asa Dotzler [:asa]]

I'm sorry. I was wrong. I do see this on my WinXP machine with d3d9. So this isn't win7 specific but it is probably d3d 9 specific. (sorry for adding any confusion).

Comment 10

[Bas Schouten (:bas.schouten)]

Attachment: Properly save and restore old cliprect

It turns out that when you set a new render target in D3D9. The scissor rect is set to the bounds of that render target. Therefore we should get the old scissor rect before anything is done to the render target, and restore it after any render target changes back to the original render target have been made.

Comment 11

[Bas Schouten (:bas.schouten)]

Attachment: Properly save and restore old cliprect v2

Remove debug code from patch.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 506431 [details] [diff] [review]
Properly save and restore old cliprect v2

What code depends on the scissor rect not changing?

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 506431 [details] [diff] [review]
Properly save and restore old cliprect v2

parentClipRect would probably be better than oldClipRect?

Comment 14

[Bas Schouten (:bas.schouten)]

http://hg.mozilla.org/mozilla-central/rev/3f19e5698520

Comment 15

[Marco Bonardo [:mak]]

Starting from today's nightly I keep seeing black a toolbox on each new tab I open, and tabs disappear... I'm on d3d9 and others on d3d10 don't seem to be able to reproduce. Please check bug 628658.

Comment 16

[Barry Marshall]

This push seems likely to have created Bug 628672.

Comment 17

[Javier Berezovsky]

Verified in Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11