1578377 - Use dark scrollbar for element with dark background

Status: RESOLVED FIXED

(Core :: Widget: Win32, enhancement)

Description

[fnkimnki]

Attachment: firefox scrollbar bug.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Enabled dark theme on Windows 10 1903 and in Firefox 68.0.2 used the "customize Firefox" tab to enable the dark theme.

Actual results:

Built-in pages, such as options and about pages, respect my dark theme choice but it's not respected on websites.

Expected results:

I expected that my Firefox scrollbar would respect my dark theme choice while on websites where people spend most of their time using, or getting distracted, by a scrollbar.

Comment 1

[Dão Gottwald [:dao]]

(In reply to mida from comment #0)

Created attachment 9090008 [details]
firefox scrollbar bug.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Enabled dark theme on Windows 10 1903 and in Firefox 68.0.2 used the "customize Firefox" tab to enable the dark theme.

The Firefox theme is irrelevant here although bug 1529323 might change that.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I think this is a widget issue, though Xidorn may have more ideas here about what's going on. I'm not familiar with our Windows scrollbar painting setup.

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

I guess this is really a question about user expectation (i.e. more a product question than a technical question). I don't think knowing how we paint scrollbars on Windows is important for whether we should consider this a bug at all.

The content scrollbars are generally considered part of the content, so I would argue that it should follow the content rather than its container (the browser). I think it is pretty clear that if a page is light, you don't want the scrollbar of, for example, a text box in the middle of the page to use a dark scrollbar, which would likely be very stark.

The situation for the scrollbar of the page is less clear, though. It feels like it might be part of the browser, so some users might expect it to follow the browser theme, but technically it is controlled by the content, i.e. the content can decide what color the scrollbar should be (via scrollbar-color for example).

If, from product perspective, we think the page scrollbars should follow the browser theme unless the content specify otherwise, I think that's technically possible for majority of cases and still conforming, but it may add complexity to the code. We would also need to think about what should happen for scrollbar in <iframe>s.

Comment 4

[fnkimnki]

"I think it is pretty clear that if a page is light, you don't want the scrollbar of, for example, a text box in the middle of the page to use a dark scrollbar, which would likely be very stark."

And vice versa for us dark users.

"but technically it is controlled by the content"

Is this a global fix? As far as I'm aware, you have to use a pretty hacky solution of creating a userChrome.css file inside a "chrome" folder or come to think of it, there's one new extension that I'm aware of that globally change the scrollbar color but it's also pretty hacky and inconsistent. I remember back when websites had more control of your scrollbar size, color and other such browser functions and sometimes it was a useability and accessibility nightmare so I'd argue that the browser, which you can control for consistency and accessibility, should have reigning control over the scrollbar and not the content.

Context menus and popups will apparently be darkened in the future according to bug 1553682 and if you consider those part of the browser and that they should be thematically consistent with the browser, I'd also argue that scrollbars are in the same category of a useability feature that should be controlled by the user and browser, not by third parties and accordingly thematically consistent with the browser.

Perhaps overlay scrollbars could also be implemented, as is a beta feature in Chrome and Vivaldi, since they're aesthetically very neutral and far less distracting from content no matter the theme as well not hindering accessibility either, from my useability perspective.

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

And vice versa for us dark users.

Well, most pages are still light by default nowadays, and I don't think there is a big momentum to change the default. But that's not my point.

I remember back when websites had more control of your scrollbar size, color and other such browser functions and sometimes it was a useability and accessibility nightmare so I'd argue that the browser, which you can control for consistency and accessibility, should have reigning control over the scrollbar and not the content.

Content still has such control. They used to be hacky, hiding the scrollbar via overflow: hidden etc and create their own scrollbar, which causing lots of usability and accessibilty issues.

It's not that bad nowadays. Many websites now use ::-webkit-scrollbar pseudo-elements for that on WebKit/Blink-based browsers, which is not ideal but not too bad. There is also a new mechanism called CSS Scrollbars, which currently only Firefox supports, allowing content to customize the scrollbar color and thickness to some extent.

Websites can use these tools to make their scrollbars fit their theme better, without sacrificing lots of usability and accessibility (unless they really want to, which they can always do anyway).

Context menus and popups will apparently be darkened in the future according to bug 1553682 and if you consider those part of the browser and that they should be thematically consistent with the browser, I'd also argue that scrollbars are in the same category of a useability feature that should be controlled by the user and browser, not by third parties and accordingly thematically consistent with the browser.

One of the difference is probably that they don't show all the time, while scrollbars do. Also websites can customize their context menu and popups as well, and more easily, and many of them have already been doing so.

Perhaps overlay scrollbars could also be implemented, as is a beta feature in Chrome and Vivaldi, since they're aesthetically very neutral and far less distracting from content no matter the theme as well not hindering accessibility either, from my useability perspective.

Overlay scrollbars are not the one-setting-fit-all solution either. If you had a look at macOS's overlay scrollbar, it uses different color pairs for light and dark background. So there still need to be different settings for different content.

That reminds me, though, that our Cocoa widget does support light and dark scrollbars, and automatically picks one based on the background color of the element it's showing for (unless overridden by the content). We can probably do something similar on other widgets on top of the custom scrollbar infrastructure.

It's not perfect (e.g. if there is a background image way different than the background color, or the element is almost completely covered by its descendant which has a very different color settings), but should be good enough for majority of cases.

Comment 6

[fnkimnki]

"That reminds me, though, that our Cocoa widget does support light and dark scrollbars, and automatically picks one based on the background color of the element it's showing for (unless overridden by the content). We can probably do something similar on other widgets on top of the custom scrollbar infrastructure."

That sounds like it'd be a great idea if it could be implemented Windows but would that be as performant compared to just changing scrollbar color according to the browser theme? It seems as it would, according to my end-user perspective, use more code and gpu resources to process the page's average color compared to just having a static scrollbar color. Anyway, I digress. You're the expert there but I and many of us dark users who've complained about the white context menus, scrollbars, etc over at /r/firefoxCSS would love these new additions. Thanks for your work.

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

use more code and gpu resources to process the page's average color compared to just having a static scrollbar color.

It's not going to process "the page's average color". It would just pick color based on the background-color property of the element. I think that's what our macOS's widget does. See nsNativeTheme::IsDarkBackground. We can just use the same function to decide whether to use light or dark scrollbar on Windows as well.

I can probably have a look at it later, so ni? myself for now. That being said, I don't think I have time in the following several weeks to work on this, so maybe that would be at least around Oct.

But I also don't think this is a difficult task itself, so if anyone wants to try, you can have a look at code around nsNativeThemeWin::DrawWidgetBackground and try to get nsNativeThemeWin::DrawCustomScrollbarPart render a dark scrollbar when nsNativeTheme::IsDarkBackground returns true.

Comment 8

[MarjaE]

This could make it harder for users to see the scrollbars.

This could give pages yet another way to screw with scrolling. As it is, many if not most web pages screw with scrolling, and this can create accessibility problems.

Comment 9

[fnkimnki]

This could make it harder for users to see the scrollbars.

Windows, Linux, iOS, Vivaldi and Chrome (beta overlay scrollbars) all use dark themes with dark scrollbars just fine. As I see it, the current white scrollbar on white pages could fit your same argument. If this enhancement is implemented, you'll just have the option of dark scrollbars on a dark page just as you have white scrollbars on white pages now. And as already noted, websites can already change the scrollbars, context menu and such, even though I don't think I've ever encountered it on modern Firefox. Maybe your point is you don't like websites having control of browser features but that's another issue . I'm also assuming this might be optional if implemented.

Comment 10

[Xidorn Quan [:xidorn] UTC+11]

Attachment: Bug 1578377 - Render dark scrollbars for element with dark background on Windows. r?jmathies

Comment 11

[Xidorn Quan [:xidorn] UTC+11]

Attachment: dark scrollbar with dark mode

This is a screenshot of the scrollbars with the patch I just submitted. The colors come from https://searchfox.org/mozilla-central/rev/b6f088f2f68d2a8ae0b49d6c8fbd7cbd3a65fa5b/toolkit/themes/shared/in-content/common.inc.css#148

Hope it would work well.

Comment 12

[Xidorn Quan [:xidorn] UTC+11]

Oops, it seems to be breaking some web-platform tests since they assume that scrollbars are opaque. I guess that means we probably cannot use the semi-transparent colors from Firefox's dark theme.

Comment 13

[Xidorn Quan [:xidorn] UTC+11]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=53c9da6df3b0aa9894af24be60847ec57ffbbdb0

Comment 14

[Xidorn Quan [:xidorn] UTC+11]

But... I believe that non-transparent scrollbar is not going to look well with dark background, as black scrollbar isn't as netural as the light gray ones with various dark colors. I just checked native macOS, and found that it as well uses semi-transparent scrollbars for dark background (as opposed to light background) even when the scrollbars are always on.

We would need to find a solution to the tests I guess, as the assumption that all scrollbars are opaque and look the same no longer holds. Maybe we can put a new pref and disable it on the tests...

Comment 15

[Xidorn Quan [:xidorn] UTC+11]

Hope it works this time...

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0b46fa6bb98477f07b1760f855b2b1eac05a0f63

Comment 16

[Xidorn Quan [:xidorn] UTC+11]

Accidentally checked in an unrelated change breaks some tests... Here's a new one: https://treeherder.mozilla.org/#/jobs?repo=try&revision=291e28c765f24bc946e6ced233b6ba6a545986c7

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9f72a5a0105d
Render dark scrollbars for element with dark background on Windows. r=jmathies

Comment 18

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/9f72a5a0105d

Comment 19

[fnkimnki]

This works well when it works. I notice widget.disable-dark-scrollbar can completely disable the feature but may I suggest also an option to force it enabled? It doesn't work on some sites, for example, reddit and youtube were the first tested and it doesn't detect when using their dark themes.

Comment 20

[Xidorn Quan [:xidorn] UTC+11]

I checked Reddit, and apparently that they set dark background on a child element of the scrollable container, so it's not using dark background from our perspective.

While it's probably not too hard to add an option to force it enabled, I suspect it wouldn't work well when a page does have a light background. Thus I think it would be better that we ask the sites to do their dark mode properly, as their current setting wouldn't work correctly for Mac users either.

Before the sites have a fix, you can always use a user style extension like Stylish or Stylus to override the style on specific sites, something like

:root { scrollbar-color: rgba(249,249,250,.4) rgba(20,20,25,.3); }

which would match the style of dark scrollbars in Firefox. I believe this leads to both less work to be done in general, and better experience overall.

Comment 21

[zamadatix]

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

I checked Reddit, and apparently that they set dark background on a child element of the scrollable container, so it's not using dark background from our perspective.

While it's probably not too hard to add an option to force it enabled, I suspect it wouldn't work well when a page does have a light background. Thus I think it would be better that we ask the sites to do their dark mode properly, as their current setting wouldn't work correctly for Mac users either.

Before the sites have a fix, you can always use a user style extension like Stylish or Stylus to override the style on specific sites, something like

:root { scrollbar-color: rgba(249,249,250,.4) rgba(20,20,25,.3); }

which would match the style of dark scrollbars in Firefox. I believe this leads to both less work to be done in general, and better experience overall.

The majority of pages where light themed for 25 years and it worked well with a light colored scrollbar, no reason to suspect the inverse wouldn't work.

The CSS workaround works most of the time but isn't guaranteed to work in all of the scenarios where widget.disable-dark-scrollbar = false and layout.css.scrollbar-color.enabled = false would.

I know I'm just one guy but I found this by searching how to force dark scrollbars now that 72 has released and was a bit disappointed the answer was do it yourself as you would have before.

Comment 22

[Xidorn Quan [:xidorn] UTC+11]

The majority of pages where light themed for 25 years and it worked well with a light colored scrollbar, no reason to suspect the inverse wouldn't work.

It might just be too light on light background, because dark scrollbars have to be semi-transparent rather than opaque.

I know I'm just one guy but I found this by searching how to force dark scrollbars now that 72 has released and was a bit disappointed the answer was do it yourself as you would have before.

I suggest you report it to Reddit.