1782623 - Scrollbar thumb nearly disappears when hovered in <select> dropdown, with dark mode and dom.forms.select.customstyling set to true

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (select with custom `background`)

STR:

1. Set dom.forms.select.customstyling to true and choose Website appearance: Dark in Firefox Preferences.
2. Load attached testcase
3. Click the dropdown arrow, and hover the scrollbar thumb (the main draggable part)

ACTUAL RESULTS:
The hovered scrollbar-thumb turns nearly the same color as the background, making it nearly invisible.

EXPECTED RESULTS:
Hovered scrollbar-thumb should remain visible, and if anything should look more "active".

I ran into this in-the-wild at https://pptform.state.gov/ , the US Government's form for filling out a printable passport-renewal application. (My passport happens to be up for renewal and I got a reminder about it today.) One of the fields in their process happens to have a dropdown menu with some styling that makes it have this issue.

STR at that site:

1. As above, be sure you have dom.forms.select.customstyling set to true and Website appearance set to Dark in Firefox preferences.
2. Visit https://pptform.state.gov/
3. Click through the read-our-terms-etc. disclaimer page.
   [it may takes a while for the next page to load, due to some server-side stuff happening]
4. Hover "Fill out online & Print" at bottom right, and click the "Submit" button.
5. Click the dropdown menu for e.g. Country Of Birth or State/Territory Of Birth
6. Hover the scrollbar thumb on the dropdown.

ACTUAL RESULTS:
[same as reduced-testcase STR] The thumb nearly disappears when hovered.

EXPECTED RESULTS:
[same as reduced-testcase STR] Hovered scrollbar-thumb should remain visible, and if anything should look more "active".

mozregression with the reduced testcase indicates that this behavior started (i.e. the thumb started disappearing when hovered) with range
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=578715b6d3fcb21c0b61996347260ef9b119d0d2&tochange=8508c35e49793fbe402ad2a706a57fabd1c2b0c4

In that range, I suspect this would've been

Bug 1707872 - Make GTK theme follow the firefox theme globally

Marking as regression from that.

Comment 1

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

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

Comment 2

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

:emilio, since you are the author of the regressor, bug 1707872, could you take a look?
For more information, please visit auto_nag documentation.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: select with near-black vs. near-white vs. default as the 'color' value

Looking at the Passport-renewal "in-the-wild" site, it looks like the relevant factor there is just a custom color on a select element -- the color declaration here:

https://pptform.state.gov/common/stylesheet.css

td.field span,
td.field input, 
td.field select, 
td.field table tbody tr td label {
	FONT-SIZE: .77em;
    COLOR: #262626;
    TEXT-DECORATION: none;
    /*border:solid 1px red;*/
    text-align: left;
    margin: 0px 5px 0px 0px; }

This seems to cause trouble regardless of how dark or light the color is, too. E.g. this testcase shows that it happens just-the-same, with a near-black as well as a near-white color. (The near-white text is hard to read, but don't focus on that; the point is that we style the hovered-scrollbar in a broken way, when a custom text color is chosen, and it's broken in the same way regardless of the brightness/darkness of the custom text color.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 showing nearly-invisible hovered scrollbar thumb (with the near-black custom text color)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 showing nearly-invisible hovered scrollbar thumb (with the near-white custom text color)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screenshot of how this looks on the live passport-renewal site

Comment 7

[Daniel Holbert [:dholbert]]

Assuming this is 'wontfix' for ESR releases, since this only affects Linux users with the nondefault not-exposed-in-UI dom.forms.select.customstyling:true configuration, which is probably a small-set of power-users with ~zero overlap with ESR. (And the bad-outcome is a UI annoyance, not anything catastrophic on an ESR-uplift-level.)

(Nonetheless: worth fixing in general, in the interests of maybe-someday being able to ship the true configuration, though it seems plans around that are hazy given the comment at https://searchfox.org/mozilla-central/rev/c2a2bf5a49626d63c4c0a5be42b6a93838c1b595/modules/libpref/init/all.js#910-911 )

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1782623 - Rename nsNativeTheme::IsDarkBackground to IsDarkBackgroundForScrollbar, and clean up a bit surrounding code. r=dholbert

This patch shouldn't change behavior. The Cocoa changes in particular
just save useless frame tree walks, since ThemeColors already computes
the color scheme in ColorSchemeForWidget.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1782623 - Set select color-scheme based on child background. r=dholbert,mconley

This makes us use light or dark select popups on supported platforms
based on the background of the select element, which allows us to use
the right scrollbar color.

Depends on D153424

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/55b84c9eac32
Rename nsNativeTheme::IsDarkBackground to IsDarkBackgroundForScrollbar, and clean up a bit surrounding code. r=dholbert

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/469683bb7d81
Set select color-scheme based on child background. r=dholbert

Comment 12

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/55b84c9eac32
https://hg.mozilla.org/mozilla-central/rev/469683bb7d81

Comment 13

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox104 to wontfix.

For more information, please visit auto_nag documentation.

Comment 14

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on Firefox 104.0(build ID: 20220818191623) on Ubuntu 22.04, using the STR and testcase from the Description. Verified as fixed on Firefox 105.0b5(build ID: 20220830185924) and Nightly 106.0a1(build ID: 20220831215447) on Ubuntu 22.04.