Reproducible: reproducible on Nightly88.0a1 windows10.

Steps to reproduce:

1. Open Hamburger menu
2. Open Sub-view and Sub-sub-view if any
3. Mouse hover "<" icon at the top-left corner
4. Repeat from step1

Actual results:
Black rectangles appears at to-right corner of the menu

Expected results:
No glitch

en-US build Nightly88.0a1 is also affected.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=97565326ca40d150f65bae3acf92178851180ca1&tochange=0c5f0b28261bfe990f6e3bc71fd57d1a32e69082

FWIW, can repro with Alice's STR. Result is very similar to first screenshot...it's underlying page content in the "black" box.
Also see it progress to messing with appmenu's scrollbar sometimes. (Win10/64, Intel Iris)

When max_update_rects was 0, I did not see the problem. Dirty rect handling seems to have a problem.

When "clearing transparent region" was disabled, I did not saw the problem, though transparent region was black. From it, WebRender seemed not re-render the cleared region correctly.

I wonder if there is a mismatch between dirty region and WebRender rendering region.

:gw, do you have any ideas what could cause the problem?

When I forced hardware WebRender to popups, Hamburger menu was not shown.

deleted

PresentableSharedImage::PresentToWindow() seems not handle dirty rects when TransparencyMode is eTransparencyTransparent.

:lsalzman, do you have any ideas that could cause the problem?

With the patch, the problem was addressed for me. I wonder if wr_swgl_clear_color_rect() does not work as expected.

(In reply to Sotaro Ikeda [:sotaro] from comment #14)

Created attachment 9209298 [details] [diff] [review]
temporal patch - Use DrawTarget::ClearRect() instead of wr_swgl_clear_color_rect() in RenderCompositorSWGL::AllocateMappedBuffer()

With the patch, the problem was addressed for me. I wonder if wr_swgl_clear_color_rect() does not work as expected.

Rather than this, try modifying the parameters to wr_swgl_clear_color_rect(). ClearRect might be clearing to black or transparent depending on surface format, whereas here we are unconditionally clearing to color (0,0,0,0). So try replacing the last 0 parameter with something like: "data && format == gfx::SurfaceFormat::B8G8R8X8 ? 1 : 0". If that doesn't help, then might be a rectangle issue.

It looks like the root cause of this bug is that in RenderCompositorSWGL, when calling wr_swgl_clear_color_rect, this can cause us to delay some clears on the default framebuffer. We just need to be careful that we flush out the clears before we actually commit the mapped buffer.

Sotaro also helped me tracked down another secondary bug (and most likely the primary cause of this, whereas the flushing issue is probably theoretical and not the real cause), related to a clear region optimization where we collapse a rectangular clear into a single row. This can clear too much of the buffer if the framebuffer in question is actually only a sub-region of a much larger buffer, and in that case we might clear areas outside the sub-region erroneously.

Unable to reproduce anymore with autoland build containing the patch above.

Backed out changeset f3aeb3726cee (bug 1698067) for Webrender failures

Log:
https://treeherder.mozilla.org/logviewer?job_id=333336752&repo=autoland&lineNumber=2156

https://treeherder.mozilla.org/logviewer?job_id=333336803&repo=autoland&lineNumber=2456

https://treeherder.mozilla.org/logviewer?job_id=333337384&repo=autoland&lineNumber=2182

https://treeherder.mozilla.org/logviewer?job_id=333336898&repo=autoland&lineNumber=2319

Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=f3aeb3726ceec8489fd4857f7a076ea1716f16c0

Backout:
https://hg.mozilla.org/integration/autoland/rev/f2134bdaf09c9e5939c787a9bd2d1475e82674a5

https://hg.mozilla.org/mozilla-central/rev/269ee52d9d9b