User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140125030205 Steps to reproduce: STR: 1. enable OMTC. 2. restart browser 3. open few tabs 4. start switching between tabs, reload 2 or 3 at same time Actual results: 5. after while nightly looks like: http://wstaw.org/m/2014/01/25/nightly.png all tabs. Expected results: Nightly suppose works and look normal Confirmed also here: http://forums.mozillazine.org/viewtopic.php?p=13324595#p13324595 While testing I was also "hit" with this crash: https://crash-stats.mozilla.com/report/index/3416090e-d930-4270-a453-3c9072140125 There are also other glitches when OMTC enabled, tabs, navbar disappears etc.

OMTC enabled. I was scrolling through about:support and blocks of text turned all black then would eventually clear up with a little more scrolling. Happens every now and then on other sites too. On Windows 8.1 Pro x64.

Confirmed here with Nightly 32bit on Windows 7 64bit.

I can confirm this too. Latest Nightly, AMD HD7850 latest WHQL driver on Windows 8.1 x64. When I resize the main window the problem goes away.

I had "layers.acceleration.force-enabled" for quite some time and glitches started to appear a few days ago. Here's an example: http://youtu.be/GZIvyGS3CO0 I'm on Linux 64 with latest nightly

This seems to cause trouble for a lot of people, who want to test e10s on windows.

I did some debugging of this today. It's pretty easy to reproduce in Windows with e10s and hardware acceleration. I'm not sure how to fix it, but here's the problem: We start with the D3D11 compositor. Later on, something tries to create a widget where mTransparencyMode == eTransparencyTransparent. We have some code [1] that chooses not to use the D3D11 compositor in that case. Without e10s, we would fall back to not using OMTC. But with e10s, we require OMTC, so we use the basic compositor instead. When we create a basic compositor, the constructor [2] sets sBackend = LayersBackend::LAYERS_BASIC. This overrides the previous value, which was D3D11. A little later on, we get to a call to CreateDeprecatedTextureHost [3]. It switches on the value of sBackend and calls CreateBasicDeprecatedTextureHost. That function asserts because aDescriptorType is TSurfaceDescriptorD3D10. It seems like the existence of Compositor::GetBackend() is fundamentally at odds with having multiple compositor backends at once, which we seem to need for electrolysis. Can we get rid of these calls? [1] http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#6540 [2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/basic/BasicCompositor.cpp#230 [3] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/TextureHost.cpp#136

We currently have the requirement that we only ever have a single compositor backend. We used to have a lot of callers depending on the static Compositor::GetBackend(), but a lot of those are gone now. I'm not sure what else is depending on this, other than simplicity. Nico, do you remember anything else that relies on this?

I looked into this a bit more and I guess we don't actually need to use OMTC at all for this transparent widget. It doesn't appear to contain remote content. I think this should be pretty easy to fix.

(In reply to Bill McCloskey (:billm) from comment #7) > I did some debugging of this today. It's pretty easy to reproduce in Windows > with e10s and hardware acceleration. I'm not sure how to fix it, but here's > the problem: > > We start with the D3D11 compositor. Later on, something tries to create a > widget where mTransparencyMode == eTransparencyTransparent. We have some > code [1] that chooses not to use the D3D11 compositor in that case. Without > e10s, we would fall back to not using OMTC. But with e10s, we require OMTC, > so we use the basic compositor instead. Gosh! Thanks for finding that. We don't handle this. At the moment some of our code expects that we have only one backend using OMTC at the same time, and we don't expect sBackend to change. It got a little bit better with a patch we landed recently but we still rely a bit on sBackend. > It seems like the existence of Compositor::GetBackend() is fundamentally at > odds with having multiple compositor backends at once, which we seem to need > for electrolysis. Can we get rid of these calls? We will need to apparently. Well, Matt, we have another reason to enforce 1-1 relationship between SurfaceDescriptor type and TextureHost class, now that we know we can't rely on Compositor::GetBackendType() :)

(In reply to Semtex from comment #0) > While testing I was also "hit" with this crash: > https://crash-stats.mozilla.com/report/index/3416090e-d930-4270-a453- > 3c9072140125 I don't have the bug number but I know there is a bug tracking this issue and someone on it.

This patch fixes the problem by not using OMTC for these transparent windows.

Sorry to say I still get the occasional black screens and corruption on my toolbars when OMTC is enabled. Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

I'm wondering whether this is another instance of AMD cards not getting along with OMTC.

Graphics -------- Adapter Description: AMD Radeon HD 7900 Series Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 3072 Device ID: 0x6798 Direct2D Enabled: true DirectWrite Enabled: true (6.3.9600.16384) Driver Date: 1-31-2014 Driver Version: 13.350.1005.0 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7900 Series Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d AzureContentBackend: direct2d AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0

Gary, please open a new bug.

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=973035

Backed out the assertion since it's triggering kind of a lot. https://hg.mozilla.org/integration/mozilla-inbound/rev/b2fc3f9509b0

Reproduced in Nightly 2014-01-27, Win 7 x64 while switching tabs. Verified fixed FF 31 RC 2.