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

VERIFIED FIXED in mozilla2.0b11



8 years ago
8 years ago


(Reporter: emorley, Assigned: bas.schouten)


({regression, testcase})

Windows 7
regression, testcase
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)


(Whiteboard: [hardblocker][fx4-fixed-bugday], URL)


(3 attachments, 1 obsolete attachment)



8 years ago
Created attachment 503143 [details]

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

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.

- HTML element rotates without rendering over Firefox chrome.

- 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


# 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:
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

8 years ago
Created attachment 503144 [details]

Comment 2

8 years ago
Suspect changesets in that range perhaps? Bug 584494: Avoid creating intermediate surfaces in D3D9 layers. r=roc a=blocking-betaN Bug 606121. Clip the cached surface in basic layers so we draw only what we need to. r=roc a=joe
blocking2.0: --- → ?


8 years ago
Keywords: testcase
Hoo, that's a bad bug.
Assignee: nobody → bas.schouten
blocking2.0: ? → final+
Whiteboard: [softblocker]
WFM with D3D10. D3D9 only?

Comment 5

8 years ago
Sounds like a problem in layers clipping.
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...
Yeah, this definitely should be a hardblocker.
Whiteboard: [softblocker] → [hardblocker]

Comment 8

8 years ago
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

8 years ago
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

8 years ago
Created attachment 506430 [details] [diff] [review]
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.
Attachment #506430 - Flags: review?(jmuizelaar)

Comment 11

8 years ago
Created attachment 506431 [details] [diff] [review]
Properly save and restore old cliprect v2

Remove debug code from patch.
Attachment #506430 - Attachment is obsolete: true
Attachment #506431 - Flags: review?(jmuizelaar)
Attachment #506430 - Flags: review?(jmuizelaar)
Comment on attachment 506431 [details] [diff] [review]
Properly save and restore old cliprect v2

What code depends on the scissor rect not changing?
Comment on attachment 506431 [details] [diff] [review]
Properly save and restore old cliprect v2

parentClipRect would probably be better than oldClipRect?
Attachment #506431 - Flags: review?(jmuizelaar) → review+

Comment 14

8 years ago
Last Resolved: 8 years ago
Resolution: --- → FIXED
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.


8 years ago
Depends on: 628658
Target Milestone: --- → mozilla2.0b11


8 years ago
Depends on: 628672

Comment 16

8 years ago
This push seems likely to have created Bug 628672.

Comment 17

8 years ago
Verified in Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.