When os compositor is enabled with the following prefs, I saw a black region on one Win10 laptop. I did not have a specific STR to reproduce the problem. It appeared occasionally.

• gfx.webrender.all: true
• gfx.webrender.compositor: true

I saw it on one laptop. But I did not see it on another Win10 PCs, then it might be a driver specific problem.

:gw, did you see a similar artifact before updating the intel driver? We might need to blacklist some old drivers.

That's different than the artifact I saw - I was seeing just a few pixels not being drawn in between tile boundaries occasionally, like a flickering effect.

I also saw the same problem on my nvidia Win10 pc, though it happened only a few times.

I could reproduce the problem on one win10 PC with the following STR, though it did not work on another Win10 PC.

• [1] Enable "Menu Bar" and "Bookmarks Toolbar"
• [2] Enable WebRender os compositor with the following prefs.
  • gfx.webrender.all:true
  • gfx.webrender.compositor:true
• [3] set youtube bookmark in the middle of "Bookmarks Toolbar".
• [4] Restart Firefox
• [5] Open new tab and open youtube video link by pushing the link by mouse.mouse
  Continue [5] until 4-5 tabs are opened.

If the problem did not happen, close tabs and re-do [5].

With the STR, black region appeared around Tab ui like Comment 2.

When DCLayer was forced to be on-opaque, I could not reproduce the problem.

When IDCompositionSurface with DXGI_ALPHA_MODE_IGNORE is used, its rendering needs to be opaque.

• https://docs.microsoft.com/en-us/windows/win32/api/dcomp/nf-dcomp-idcompositiondevice2-createsurface

I wonder if there is a case that non-opaque rendering could happen to opaque tile.

I see the same problem on macOS sometimes. The black layer is definitely opaque, and probably expecting to be transparent. I find this easier to reproduce when switching between tabs that paint in the parent process and tabs that paint in the content process. In the case of this screenshot, the black areas appeared when switching to about:config, and they were sticky enough that I could flip the gfx.core-animation.tint-opaque pref without destroying the glitch, and take a screenshot.

On macOS, most of the chrome seems to be painted in the slice behind the content area, but some of it is painted in front: tab close buttons, some parts of the active tab, and some of the toolbar buttons (especially the back/forward button). (This should probably be fixed, but that's a different issue.)

I think what may happen here could be something like the following. I don't know this code at all so this is pure conjecture based on observed behavior:

1. A slice starts out with a small size. A clip to the slice size is applied to a tile. Within this clip, the tile content is opaque, so we create an opaque tile.
2. New content is added to the slice, possibly in a different part of the browser window that draws into a different tile.
3. This expands the slice size, so the clips on the tiles are expanded to that new size.
4. Under the expanded clip, the existing tile now no longer has opaque content: Transparency was added around the content.
5. However, the opaqueness change of the tile not detected because nothing else in the existing tile changes. So the tile stays opaque instead of being recreated as a non-opaque tile.

Glenn, does something like this sound reasonable?

Hmm, looking at the screenshot again, I think something slightly different may be happening. It's likely that the back button is always part of the foreground slice, and tab switching just moves the location of the active tab's close button in the foreground slice. And it's the tab close button's tile that's wrongly opaque, not the back button's tile. But anyway, maybe my previous comment comes close enough that Glenn might find the bug even so.

I have been unable to reproduce this locally.

However, I can see a possible code path where the opacity flag state change could get missed, which might result in a bug matching what you are seeing.

When you have time, could you apply this patch and see if it resolves the issue on your machine?

(In reply to Glenn Watson [:gw] from comment #12)

When you have time, could you apply this patch and see if it resolves the issue on your machine?

The patch addressed the problem for me!

https://hg.mozilla.org/mozilla-central/rev/ea818e25e302

I was unable to reproduce the issue on several Windows machines, this issue seems verified as fixed based on comment 13, marking it as such.