Bumping this thread a bit because of the additional attention that is being placed on OS supported dark modes in Firefox.

When playing with browser.in-content.dark-mode, I needed to switch my GTK theme over to Adwaita dark, and the scrollbars in Firefox are really not good looking with this theme and the resulting dark mode in Firefox.

GNOME Web does this very well and would be a good place to copy the look and feel from, and it would be a nice fit and finish item, alongside the rest of the work that is happening on dark modes in Firefox.

How is this going to be handled with NNT?

Overlay scrollbars should already work if you create the ui.useOverlayScrollbars and set it to 1, I'd think.

Hum, partially indeed: the scrollbar stays the standard one, but disappears when not scrolling. However this is not proper overlay scrollbar as in other GTK applications (especially, it keeps a background…).

Probably early-returning in nsNativeThemeGTK::DrawWidgetBackground when aAppearance is ScrollbartrackHorizontal or ScrollbartrackVertical, and overlay scrollbars are enabled, would achieve what you want... Perhaps we should do the same in the non-native theme too.

Mind that proper GTK overlay scrollbars aren't transparent when hovered over. They're normal-width and largely (but not completely) opaque when hovered, thin and transparent while scrolling in other ways, and invisible otherwise.

The thin scroll slider also has a dark fill and a light stroke, so stays visible regardless of the backdrop color.

Correction: The scrollbars are thin and transparent when scrolling in other ways or the mouse moves inside the viewport.

Do you know how are other GTK apps supposed to use them?

Do they get to choose between overlay / non-overlay scrollbars? Or do they always get one based on user settings? If the former then perhaps we should be looking at different GTK CSS nodes in some cases, if the later then we should probably hook that setting in somehow.

The GtkScrolledWindow widget defaults to using overlay scrollbars.

The app can force the widget to use permanent scrollbars by setting its overlay-scrolling property to FALSE.

The user/environment can request permanent scrollbars by setting the gtk-overlay-scrolling global setting to FALSE, in which case the per-widget setting is ignored. However, the app can override this setting.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)

Overlay scrollbars should already work if you create the ui.useOverlayScrollbars and set it to 1, I'd think.

Pardon my curiosity. Any particular reason why that about:config entry needs to be of type number?

(In reply to Mel from comment #21)

Pardon my curiosity. Any particular reason why that about:config entry needs to be of type number?

I don't know for ui.useOverlayScrollbars in particular, but generally, Firefox has tons of boolean-ish about:config entries that are numbers rather than booleans, for when the behavior to be configured is configurable more subtly than just ON/OFF. In addition to 0,1, Firefox then uses 2,3,4 for the slightly-different behaviors implemented. Case in point: HTTP Referrer options.

(In reply to Jan Alexander Steffens [:heftig] from comment #20)

The GtkScrolledWindow widget defaults to using overlay scrollbars.

The app can force the widget to use permanent scrollbars by setting its overlay-scrolling property to FALSE.

The user/environment can request permanent scrollbars by setting the gtk-overlay-scrolling global setting to FALSE, in which case the per-widget setting is ignored. However, the app can override this setting.

So im guessing that firefox disables overlay-scrolling? Since i have the option enabled in my conf yet i see the whole scrollbar while scrolling.

This is after setting useoverlayscrollbars to "1".

Video for context: https://imgur.com/a/Z7KVldv

(In reply to Rohan from comment #23)

(In reply to Jan Alexander Steffens [:heftig] from comment #20)

The GtkScrolledWindow widget defaults to using overlay scrollbars.

The app can force the widget to use permanent scrollbars by setting its overlay-scrolling property to FALSE.

The user/environment can request permanent scrollbars by setting the gtk-overlay-scrolling global setting to FALSE, in which case the per-widget setting is ignored. However, the app can override this setting.

So im guessing that firefox disables overlay-scrolling? Since i have the option enabled in my conf yet i see the whole scrollbar while scrolling.

This is after setting useoverlayscrollbars to "1".

Video for context: https://imgur.com/a/Z7KVldv

Firefox does not use GTK's scrollbars but draws its own, disconnected from GTK's overlay scrollbar settings. I was merely answering the preceding comment.

In bug 1701846 I implemented some behavior closer to the native ones, mostly intended so my eyes don't bleed when testing macos-like stuff. But someone motivated enough could change the hard-coded fade durations etc to be taken from the GTK theme (if they're configurable), or at least make them more similar to adwaita.

Changing the drawing so that it behaves more like the native one etc should also be straight-forward.

At least from my POV, the issue seems resolved since :emilio work. We have overlay scrollbars, that disappear when not scrolling, are thin while not hovered and enlarged when they are.

They seem to work pretty well. Is there no desire to enable them by default?

Maybe? Is there a gtk setting we could hook this to? Or does GTK3+ apps always use overlay scrollbars? gnome-terminal doesn't seem to for example.

If there is no GTK setting, perhaps we should expose this in about:preferences (probably near autoscroll and such). Gijs, would that be reasonable?

As I mentioned in comment #20, there's the gtk-overlay-scrolling global setting. It's on the GtkSettings that's already in use in a few places.

PS: GNOME Terminal is a special case since it uses an explicit scrollbar widget instead of the standard GtkScrolledWindow. This is an old bug.

Ah, d'oh, I had missed that, sorry. So we could trivially implement that, or alternatively let the user decide in about:preferences.

I don't particularly mind either way, though given that:

• We've never had overlay scrollbars.
• I don't see an obvious graphical way for most users to change gtk-overlay-scrolling (tried gnome-tweaks, GNOME settings, and KDE system settings, none of them have a tweak for that unless I've missed it).

Perhaps a checkbox in about:preferences is more discoverable... So I think I'm going to try that first, but let me know if you disagree.

You can find the setting with dconf-editor, searching for overlay-scrolling.

We might want to do this on Windows 11 as well, but Windows 11 has a
system-wide preference with UI so let's not do that just yet at least,
UI-exposed preference.

Let's try.

Depends on D138502

(In reply to Jan Alexander Steffens [:heftig] from comment #32)

You can find the setting with dconf-editor, searching for overlay-scrolling.

I see. Still I'd argue that most users aren't gonna look there if they see their scrollbars changed and they don't like it :)

Enabling by default seems to need a fair amount of test updates. At a glance none of them seem problematic, but I think this would be the first desktop platform we test with overlay scrollbars since on mac IIRC we set the systems on automation to use non-overlay scrollbars:

https://treeherder.mozilla.org/jobs?repo=try&revision=7d8963e125c80dcdf38417f753e691da75a7e540

Given that, it might be reasonable to set this pref to false for automation or so... I'll take a look tomorrow.

There are a fair share of desktop mochitests that depend on having
scrollbars take space (and that are useful to test the non-overlay
scrollbar codepath).

Also, GTK overlay scrollbars have opacity animations (they fade out), so
they are much more prone to useless fuzzy intermittent failures.

We get overlay scrollbar testing via Android (Android scrollbars also
don't have animations, which is nice). We seem to disable them for macOS
as well, afaict, just at the system level, so this is consistent with
that.

I think a checkbox is probably OK.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #35)

I see. Still I'd argue that most users aren't gonna look there if they see their scrollbars changed and they don't like it :)

It might be reasonable to require both the setting and the preference to be true? In case some users did express a global preference for non-overlay scrollbars.

(In reply to Jan Alexander Steffens [:heftig] from comment #39)

It might be reasonable to require both the setting and the preference to be true? In case some users did express a global preference for non-overlay scrollbars.

I don't know, that means that the checkbox in about:preferences wouldn't work if you have that setting set to false, which would be quite unfortunate IMO.

https://hg.mozilla.org/mozilla-central/rev/3d3349b4a657
https://hg.mozilla.org/mozilla-central/rev/8720b5f8902c
https://hg.mozilla.org/mozilla-central/rev/b49c4d84f401

So, why it does not follow system settings?

~/.config/gtk-3.0/settings.ini
gtk-overlay-scrolling=false

Why it's still animated if I have preference set to reduce motion?

(bug 1690812 explains the look)

Build 20220215092702 on Manjaro KDE.

(In reply to gwarser from comment #44)

Created attachment 9263944 [details]
GIF 2022-02-15 14-41-38.gif

So, why it does not follow system settings?

~/.config/gtk-3.0/settings.ini
gtk-overlay-scrolling=false

See discussion above as for why.

Why it's still animated if I have preference set to reduce motion?

File a bug and ni? me please, happy to fix.

This fix seems to trigger an undesired behavior with a static element inside (and above) a element with a scrollbar, see https://jsfiddle.net/8vcnjy40/13/

Here you can scroll the underlying element by hovering its scrollbar which is unexpected.

(In reply to gterras from comment #46)

This fix seems to trigger an undesired behavior with a static element inside (and above) a element with a scrollbar, see https://jsfiddle.net/8vcnjy40/13/

Here you can scroll the underlying element by hovering its scrollbar which is unexpected.

Seems an issue on macOS already, afaict? But can you file a new bug about this? I can take a look.

Hi thanks see my report here https://bugzilla.mozilla.org/show_bug.cgi?id=1756831