1777135 - Scrollbar thumb disappears when hovered, in dark mode presentation of plaintext documents

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: view this in dark mode, and hover the scrollbar thumb

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

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of the STR before this regressed

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.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of the STR after this regressed [showing the bug]

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.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast comparing plaintext document to about:newtab, with both settings of "always show scrollbars" [showing the bug]

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.

Comment 4

[Daniel Holbert [:dholbert]]

(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.)

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 6

[Emilio Cobos Álvarez (:emilio)]

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

Comment 7

[Emilio Cobos Álvarez (:emilio)]

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

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: about:support "raw data" (JSON)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: log output from a brief `MOZ_LOG=LookAndFeel:5 ./mach run` session

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1777135 - Part 1: make nsPresContext::DefaultBackgroundColor account for default-background color-scheme. r=dholbert

And remove one unused caller.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1777135 - Part 2: Improve nsNativeTheme::IsDarkBackground by accounting for default bg color. r=dholbert

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

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (html instead of plaintext)

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.)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: reference case 2

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).

Comment 14

[Daniel Holbert [:dholbert]]

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.)

Comment 15

[Daniel Holbert [:dholbert]]

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.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

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

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/86a8cb8c3bdc
Part 1: make nsPresContext::DefaultBackgroundColor account for default-background color-scheme. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/69b62329c1d8
Part 2: Improve nsNativeTheme::IsDarkBackground by accounting for default bg color. r=dholbert

Comment 18

[Iulian Moraru]

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

Comment 19

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

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.