1575914 - With some GTK themes, the track color from scrollbar-color is ignored, potentially causing poor or no contrast between track and thumb

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Botond Ballo [:botond]]

Attachment: Screenshot of BMO scrollbar

STR

1. Run Firefox nightly or release on Linux. In case the distro / desktop environment matters, I am using Debian 9 with KDE Plasma 5.8.
2. Load any BMO page that's scrollable.

Expected results

There is a good amount of contrast between the color of the scrollbar thumb and the color of the scrollbar track.

Actual results

The two colors are almost the same, making it very difficult to distinguish the scrollbar thumb. See attached screenshot.

Comment 1

[Botond Ballo [:botond]]

Attachment: Screenshot of regular site scrollbar

Note that this only affects BMO. On other pages, the contrast is good (see attached screenshot).

Comment 2

[Botond Ballo [:botond]]

As this affects both nightly and release, I assume this is the result of a recent site change, rather than a Firefox change.

Comment 3

[Kohei Yoshino [:kohei]]

Attachment: Screenshot of BMO scrollbar on Ubuntu

Hmm, I haven’t changed the scrollbar style since Bug 1552885. On Ubuntu 19.04, it looks similar to Windows.

Comment 4

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #0)

In case the distro / desktop environment matters, I am using Debian 9 with KDE Plasma 5.8.

Actually, I have several machines with this configuration, and I'm only seeing this bug on one of them. I wonder what is different...

Comment 5

[Kohei Yoshino [:kohei]]

So this is probably not an issue in BMO. Moving to Core.

Comment 6

[Botond Ballo [:botond]]

Another thing that happens on that machine only, is Firefox displays scrollbar buttons. I suspect the two differences are related.

Comment 7

[Botond Ballo [:botond]]

Ah! It has to do with changing the GTK3 theme (which in KDE is done via System Settings --> Application Style --> GNOME Application Style (GTK) --> Select a GTK3 Theme) from Default to Breeze. With Breeze, this lack-of-contrast problem appears.

Comment 8

[Botond Ballo [:botond]]

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #5)

So this is probably not an issue in BMO.

Agreed, this seems like a bug in the implementation of scrollbar-color for GTK.

At the same time, one could argue that BMO could be more conservative in its adoption of new web platform features like scrollbar-color while edge case interactions like this are ironed out.

Comment 9

[Botond Ballo [:botond]]

I had a look with devtools. The value of the scrollbar-color property has two components: the thumb color and the track color. BMO chooses values which have reasonable contrast with each other, so if both were applied, things would be fine.

However, it looks like the thumb color is applied, but the track color is not. Instead we get the track color from the desktop theme, which for Breeze is very close to the custom thumb color.

Comment 10

[Xidorn Quan [:xidorn] UTC+10]

That's very interesting... System theme shouldn't affect the display of custom scrollbar with GTK. The system rendering is explicitly denied via nsNativeThemeGTK::ThemeSupportsWidget.

Is it possible that system rendering of scrollbar is checked somewhere else in the codebase? Or the system somehow hijack the browser?

If it doesn't always look like that, maybe check what it looks like with Firefox 64 (where scrollbar-color was initially enabled) given the settings?

Comment 11

[Botond Ballo [:botond]]

With Firefox 64 it looks fine! I will try to get a regression window.

Comment 12

[Kohei Yoshino [:kohei]]

(In reply to Botond Ballo [:botond] from comment #8)

At the same time, one could argue that BMO could be more conservative in its adoption of new web platform features like scrollbar-color while edge case interactions like this are ironed out.

I’m really enjoying bringing latest platform features into the 21-year-old legacy application ;-) Perhaps I should create custom scrollbars instead… With Shadow DOM and the Resize Observer API, it will soon be much easier to do it.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Jan did lot of scrollbar work so he should know more.

Comment 14

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #11)

With Firefox 64 it looks fine! I will try to get a regression window.

Hmm, on my office machine Firefox 64 shows the poor contrast as well.

Comment 15

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #14)

(In reply to Botond Ballo [:botond] from comment #11)

With Firefox 64 it looks fine! I will try to get a regression window.

Hmm, on my office machine Firefox 64 shows the poor contrast as well.

Yeah, sorry, I think I made a mistake when I said it looked fine with Firefox 64, because I can't replicate that result on the original machine either.

I'm afraid it looks like this has been broken ever since the introduction of scrollbar-color.

Comment 16

[Martin]

This is still an issue in Firefox 74. I opened an issue with some more information (but closed it as a duplicate once I found this bug): https://bugzilla.mozilla.org/show_bug.cgi?id=1610782

I can confirm that switching to a different GTK theme fixes it, and it seems like the scrollbar track's color is affected by the GTK theme, but the scrollbar thumb stays exactly the same.

Comment 19

[Xidorn Quan [:xidorn] UTC+10]

I failed to figure out how to enable Breeze on my Ubuntu 19.10, but I think I probably know the reason of this issue.

Could you try this try build and see if it fixes the issue for you? https://treeherder.mozilla.org/#/jobs?repo=try&revision=b7ae33a618ebd2a0fcbd9f58ae258e465668ee58

Comment 20

[Botond Ballo [:botond]]

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #19)

Could you try this try build and see if it fixes the issue for you? https://treeherder.mozilla.org/#/jobs?repo=try&revision=b7ae33a618ebd2a0fcbd9f58ae258e465668ee58

I'm not able to reproduce the original problem any more. I tried a recent nightly, a nightly from the time this bug was filed, and your Try build, and the scrollbars look the same (with good contrast between track and thumb) in each one.

Possibly the Breeze theme has changed since the time I filed this bug (I've since upgraded from Debian 9 to Debian 10).

Comment 21

[Botond Ballo [:botond]]

However, I am able to reproduce the issue on the page from the duplicate bug 1616098 (https://developer.mozilla.org/fr/docs/Web/CSS/scrollbar-color), and I can confirm that your patch fixes it!

Comment 22

[Xidorn Quan [:xidorn] UTC+10]

That's a great news! Thanks for checking!

Comment 23

[Xidorn Quan [:xidorn] UTC+10]

Attachment: Bug 1575914 - Treat scrollbar tracks as scrollbar part. r?jmathies

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6a03a1ccc1fa
Treat scrollbar tracks as scrollbar part. r=jmathies

Comment 25

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/6a03a1ccc1fa

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta uplift when you get a chance.

Comment 27

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 9132184 [details]
Bug 1575914 - Treat scrollbar tracks as scrollbar part. r?jmathies

Beta/Release Uplift Approval Request

• User impact if declined: Linux users with certain theme may see incorrect scrollbar colors on websites using scrollbar-color property
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Custom scrollbar rendering have smoke test covered on all platforms, so it's not very likely to cause regression on systems other than Linux.
• String changes made/needed: n/a

Comment 28

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #26)

Please nominate this for Beta uplift when you get a chance.

I'm not fully convinced that this needs to uplift, but I'm not against it either, so nominated anyway.

Comment 29

[Pascal Chevrel (relman team) -> :pascalc]

Comment on attachment 9132184 [details]
Bug 1575914 - Treat scrollbar tracks as scrollbar part. r?jmathies

The patch is minimal, baked on nightly for a week and it is indeed quite visible with the Adwaita theme which is the default Gnome theme, looks safe in early betas, uplift approved for 75 beta 6, thanks.

Comment 30

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/b6bf700c538b

Comment 31

[Ian Nartowicz]

The Gtk theme I have uses a linear gradient as a background image for the thumb. It changes to a high-contrast colour on hover, which Firefox completely misses. If I edit the theme to give the thumb a colour other than transparent, that is picked up by Firefox although not the gradient.

Comment 32

[Botond Ballo [:botond]]

(In reply to Ian Nartowicz from comment #31)

The Gtk theme I have uses a linear gradient as a background image for the thumb. It changes to a high-contrast colour on hover, which Firefox completely misses. If I edit the theme to give the thumb a colour other than transparent, that is picked up by Firefox although not the gradient.

Probably best to file a new bug so it doesn't get overlooked. Attaching screenshots also helps.