First noticed on the 2/27 Nightly, but also reproduces with 2/28. Random interface elements (new tabs, the URL preview in the lower-right corner) are rendered as black rectangles, but I couldn't find any STR. However, Facebook's overlays are always rendered as black rectangles. To reproduce, I need to log in and click the "planet" icon in the top-right corner. The attached screenshot is unredacted and shows what Facebook actually looks like on my screen once I toggle the overlay. Also, while writing this, the text just turned black and I can't see what I'm typing any longer. I have layers.acceleration.force-enabled as "true", webgl.disabled as "true", and the following graphics information: Adapter Description: nouveau -- Gallium 0.4 on NVC1 Device ID: Gallium 0.4 on NVC1 Driver Version: 3.0 Mesa 9.2.5 GPU Accelerated Windows: 1/1 OpenGL (OMTC) Vendor ID: nouveau windowLayerManagerRemote: true AzureCanvasBackend: cairo AzureContentBackend: cairo AzureFallbackCanvasBackend: none AzureSkiaAccelerated: 0

(In reply to Sean Stangl [:sstangl] from comment #0) > I have layers.acceleration.force-enabled as "true" I think that's what makes the difference. I have that and OMTC activated in my Firefox Nightly and I'm seeing this, e.g. the graph on https://crash-stats.mozilla.com/home/products/Firefox is completely black - in other places a frame is rendered as a black square and then a few seconds later replaced by a correct rendering. On the SeaMonkey trunk builds that I compile as well, I do not have acceleration or OMTC turned on and things always render correctly. In my case that's with the following info in about:support on Firefox Nightly: Adapter Description: Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Desktop Device ID: Mesa DRI Intel(R) Sandybridge Desktop Driver Version: 3.0 Mesa 10.0.3 GPU Accelerated Windows: 5/5 OpenGL (OMTC) Vendor ID: Intel Open Source Technology Center WebGL Renderer: Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Desktop windowLayerManagerRemote: true AzureCanvasBackend: cairo AzureContentBackend: cairo AzureFallbackCanvasBackend: none AzureSkiaAccelerated: 0 As a comparison, those values are the differences in SeaMonkey's info: GPU Accelerated Windows: 0/2 Basic windowLayerManagerRemote: false

Bug 973035 is possibly related to this.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > Bug 973035 is possibly related to this. I don;t believe it is. The reporter of that bug had AMD/ATI graphics. I only see this bug with Intel Sandybridge. I do not see on any of my AMD/ATI systems, or the one with NVIDIA graphics.

hg bisect identified: The first bad revision is: changeset: 170584:5ae2a4860eca user: Matt Woodrow <mwoodrow@mozilla.com> date: Sat Feb 22 22:22:43 2014 +1300 summary: Bug 974709 - Use a separate texture for each X11TextureSource and keep the pixmap bound. r=nical

Possibly duplicate of bug 977963

I verified that backing out bug 974709 avoids this issue for me.

(In reply to Bill Gianopoulos [:WG9s] from comment #3) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > > Bug 973035 is possibly related to this. > > I don;t believe it is. The reporter of that bug had AMD/ATI graphics. I > only see this bug with Intel Sandybridge. I do not see on any of my AMD/ATI > systems, or the one with NVIDIA graphics. Ignore my comment here. It turns out that I don;t see the issue I do on Gmail, which is what I was using for the bisect on my system with AMD/ATI graphics. However, it has black all over the place on Facebook. Backing out bug 974709 fixes the AMD/ATI black on Facebook issue also.

Oh I still do not see this issue at all on my system that has Nvidia graphics.

(In reply to Bill Gianopoulos [:WG9s] from comment #8) > Oh I still do not see this issue at all on my system that has Nvidia > graphics. Note that this bug has been reported initially on an NVidia-powered system, but with the open drivers (nouveau/Gallium3D) and not the proprietary/binary ones. Of course, it looks like you need to make sure that OMTC is actually enabled or you will not see the issue. If I turn off OMTC, things are fine here as well.

I see the bug here with OMTC disabled, and layers acceleration force-enabled under AMD/ATI graphics. So, if 973035 is OMTC only, I would guess that is a different issue but same symptoms. Also, bug 973035 was reported on Feb 14th, and the regression bug here did not land until Feb 27th.

Well, all the about:support info posted here and on bug 973035 says OMTC in "GPU Accelerated Windows", but it might very well only be acceleration. The landing of bug 974709 at least matches the time of my regression pretty much, from what I remember. It's entirely possible that bug 973035 can be a different issue, of course. Note that in comment #2 I only said *possibly related*, if I would have taken for granted that it was the same thing, I would have marked one as a dupe of the other. ;-)

The pending patch on Bug 977963 avoids this issue.

Does this still reproduce?

Not since 2014!