STR:

1. View the attached testcase, using a fresh profile on Linux (or at least using overlay scrollbars (i.e. "always show scrollbars: [not checked]" in Firefox preferences -- this is the default configuration).
2. Look at the scrollbar that appears (and then fades out) when the page loads.
3. Resize your window vertically.

ACTUAL RESULTS:

• The scrollbar that appears in step 2 may be a different brighter color at the top half vs. the bottom half. (this may or may not happen depending on your window size, and possibly other ~random factors; read on...)
• When you resize your window, the top half of the scrollbar blinks to be brighter or the same brightness as the lower half of the scrollbar, at various window sizes.

EXPECTED RESULTS:
No such difference in color between the top half and bottom half of the scrollbar.

I can reproduce this as far back as the first Nightly that supported overlay scrollbars (i.e. the first Nightly after bug 1147847 landed). So: calling this a regression from bug 1147847

Note: my testcase uses background: blank, but I can reproduce this with the default background color too.

I ran into this in-the-wild at https://messages.google.com , i.e. the desktop-web-browser GUI for remotely controlling Android's text messaging app. In that case, I sometimes see a variety of graphical corruption in the scrollbar color, I think because there's some transparency in their scrollbar-color which makes this even weirder.

Here's a screencast showing the corruption that this causes in the scrollbar at Android messages. Look at the bottom right corner of the window as I resize it in this screencast -- the vertical bar with variously-flashing pixel colors there is the overlay scrollbar.

Note that in comment 3's screencast, everything is fine from around t=0:20 to t=0:29, but for most of the rest of the video, the top half of the scrollbar is a different color from the bottom half.

I'm using Ubuntu 22.04.3 with Firefox 118.0a1 (2023-08-24) (64-bit). I tried rebooting just in case that might help (it didn't).

A few additional notes:

• I ran into this in a Wayland desktop session (using wayland-enabled Firefox nightly -- no special configuration to opt in/out, just running in an Ubuntu-with-Wayland session in a fresh Firefox Nightly profile).
• In that environment, my Firefox happens to automatically fall back to software WebRender (as shown in about:support). I can't test hardware webrender in that environment right now; I startup-crash if I try to force it with gfx.webrender.all:true.
• I cannot reproduce when using Xorg instead (selecting the non-wayland option at the Ubuntu login screen).

Aha, in Ubuntu-with-Xorg, I get hardware-webrender by default (which works just fine in general and from the perspective of this bug). In that environment, I can only reproduce if I force software webrender (gfx.webrender.software).

So: I think this is a Software WebRender bug, with rendering extremely-thin partially-transparent things (like the overlay scrollbar in this case) --> Reclassifying as Graphics:WebRender.

Set release status flags based on info from the regressing bug 1147847

:emilio, since you are the author of the regressor, bug 1147847, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

I also see the same regression range if I force enable software webrender.

Any ideas, Lee?