STR:

1. Put Firefox in Dark Mode (about:preferences "Website Appearance" section)
2. Load some long plaintext doc, e.g. the one I'm attaching here.
3. Hover the scrollbar "thumb" (the draggable piece)

ACTUAL RESULTS:
The scrollbar "thumb" disappears (or changes to the same color as the track?) when hovered.

EXPECTED RESULTS:
Scrollbar thumb should remain visible.

I'm using Ubuntu 22.04; and I can reproduce this bug regardless of whether Ubuntu itself is light-themed vs. dark-themed.

mozregression says this regressed from bug 1743027, i.e. from this changeset:
https://hg.mozilla.org/integration/autoland/rev/e2dc9aa72ad9

This is a screencast of me hovering and then clicking-and-dragging the thumb, using the taskcluster build from 42a64fe0c062cd296da3ab22a14f938fd2663caa (the parent of the regressing commit).

Note that the scrollbar thumb remains visible when hovered.

This is a screencast of those same steps in e2dc9aa72ad982a4d2e9b3ed75757a892a14e1f4 (the regressing commit).

Note that the scrollbar thumb disappears (or changes to the same color as the track) when hovered.

Also notable: the behavior is slightly different depending on whether "always show scrollbars" is enabled. But the thumb disappears when hovered, regardless of that setting.

Here's a screencast comparing plaintext documents to about:newtab, using current Nightly.

At the start of the video, I've got "Always show scrollbars" at its default setting (off, i.e. using overlay scrollbars).

Then partway through the video, I toggle it to on (for traditional scrollbars). You can see how the thumb disappears when hovered in both configurations.

(side note: with the default overlay-scrollbars configuration, I think the scrollbar track is unintentionally too bright when you just hover the track, too. On about:newtab, the hovered track is extremely subtle -- nearly the same color as the surrounding background. And the same is true at e.g. this bugzilla page here.)

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

Can you attach about:support info? And maybe a log with MOZ_LOG=LookAndFeel:5 of the startup?

Ah, though given what the change is, I think I know what's going on.

And remove one unused caller.

Since callers want just an effective color to compute whether it's dark,
we simplify the API a bit too.

This makes sure we find the dark background in plain text documents.

Depends on D151017

FWIW: while doing some poking around to see if I could generate an automated testcase, I realized that this reproduces with HTML as well -- not just plaintext.

It specifically affects color-scheme: dark; content[1] without any specified background-color, as is the case for plaintext "testcase 1" as well as this "testcase 2".

(The attached patches do seem to fix both the original testcase as well as this new testcase, which is great.)

Here's a reference for testcase 2, where I've just explicitly-specified the observed background-color that my system uses for testcase 2 (which happens to be #1c1b22).

This is sufficient to get me "expected results" in Nightly. The testcases look identical except the scrollbars look quite different (even when un-hovered, including/especially when overlay scrollbars are disabled).

emilio, I noticed the patches don't have a testcase included right now. Perhaps testcase 2 and reference case 2 are useful for generating a testcase? (Perhaps with some prefs set in reftest.list so that the default background-color that we use in the testcase is something predicable/hardcoded rather than #1c1b22, to make it easier to reliably match in the reference case in a future-proof way.)

Side note: with testcase 2, this regression goes back further, all the way to the implementation of color-scheme.

Using this command (manually enabling the color-scheme pref, for the benefit of builds back before it was on by default)...

mozregression \
--pref "layout.css.color-scheme.enabled:true" "security.sandbox.content.level:0" \
  "widget.gtk.overlay-scrollbars.enabled:false" \
--good 2021-10-20 --bad 2021-11-20 \
-a https://bug1777135.bmoattachments.org/attachment.cgi?id=928477

...I get this "regression range" (which I'm putting in quotes since the before results aren't exactly "expected", as discussed below):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fa78343a890f5f4983898fccdb3d691cad677fb7&tochange=48bb39e937c595808b2edea7970dafcb925755cd

Before that range, testcase 2 simply renders as black text on a white background, with a regular traditional scrollbar; entirely color-scheme unaware.
After that range, testcase 2 renders with a dark color-scheme, but with the wrong color scrollbar (particularly when hovered) as discussed here.

So: really, this is a regression or rather followup-work-from bug 1525107.

Yeah we disable dark scrollbars on reftests but we could enable them here.

https://hg.mozilla.org/mozilla-central/rev/86a8cb8c3bdc
https://hg.mozilla.org/mozilla-central/rev/69b62329c1d8

I managed to reproduce this issue on Firefox 103.0(build ID: 20220718155818) on Ubuntu 22.04. Verified as fixed on Firefox RC 104.0(build ID: 20220816115024) and Nightly 105.0a1(build ID: 20220816190318) on Ubuntu 22.04, macOS 12, Windows 10.