Closed Bug 1147847 Opened 9 years ago Closed 2 years ago

[GTK3] Implement overlay scrollbars

Categories

(Core :: Widget: Gtk, enhancement, P5)

Product:
Core
Component:
Widget: Gtk
Platform:
x86_64
Linux
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
99 Branch
Tracking Flags:
Tracking Status
firefox99 --- fixed

People

(Reporter: stransky, Assigned: emilio)

References

(Blocks 2 open bugs, Regressed 1 open bug)

Details

(Whiteboard: tpi:+)

Attachments

(5 files)

overlay-scrollbars behavior on Ubuntu 16.04.mp4
541.05 KB, video/mp4
Details
Bug 1147847 - Allow users to enable overlay scrollbars on Linux from about:preferences. r=Gijs!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1147847 - Enable GTK overlay scrollbars on Nightly and Early Beta. r=stransky
48 bytes, text/x-phabricator-request
Details | Review
Bug 1147847 - Disable overlay scrollbars for testing. r=jgraham!
48 bytes, text/x-phabricator-request
Details | Review
GIF 2022-02-15 14-41-38.gif
46.78 KB, image/gif
Details 
Gtk3 supports overlay scrollbars so we may consider to implement it too in Gtk3 port. A similar code already exists for Windows 8 Metro and MacOS.
I support this idea. It would be exceedingly nice from a UX perspective.
Severity: normal → enhancement
Without overlay scrollbars, the default theme on ubuntu is glitchy and ugly.]

Glitchiness:
   Sometime the overlay scrollbar animates, other times it's stuck in the "onhover" position, but the scrollbar is always takes up the full space.
s/Sometime/Sometimes/
This will also look nicer under the stock gtk3 default theme (Adwaita). Mimicking native application behavior is always a welcome improvement.
Horizontal overlay-scrollbar has different hover behavior.
How about next steps?
Priority: -- → P5
Whiteboard: tpi:+
In https://bugzilla.mozilla.org/show_bug.cgi?id=1337361 I’ve added some screenshots on how it looks like in other applications and how it does in Firefox. In one word, ugly. It’s especially worse on breeze (default KDE Plasma theme), where the onhover scroll bar is very large. Hopefully, being on HiDPI I have a partial workaround for this. But that’s sub-optimal.
Interestingly, this was apparently resolved in Firefox 60.0, 59.0, 58.0 and 57.0 (I haven't checked earlier versions, so I'm not sure exactly when), for both horizontal and vertical scrollbars, but the issue has fully reappeared in 61.0 — overlay scrollbars have disappeared for both horizontal and vertical scrollbars (they're constantly at full width/height irrespective of whether they're hovered over or not). The issue is also present in Nightly 63.0a1 (2018-07-10).

System: Ubuntu 16.04. For Firefox 61.0 I tested with both the version from the system repositories and directly from Mozilla.
I also like to note that there is an inconsistency in design that would be fixed with the use of overlay scrollbars:
The topmost scrollbar of the viewport has a solid, opaque background (gtk theme's window background instead of scrollbar background). That is usually the scrollbar belonging to the <body> element, but might also be the scrollbar of the <html> element, in which case the <body> scrollbar looks different than usual.

This bugzilla is also a good example for the inconsistency because due to the header, not the entire viewport is scrollable. If the gtk theme's scrollbar background is transparent, it will affect the scrollbar on this page, but not on pages where the whole viewport does scroll.

Another reason for overlay scrollbars is that they are reducing the uniqueness of the browser, improving fingerprint resistance because the viewport size is not affected by the overlay scrollbar. Usually it is and the width depends on the used GTK theme.
See Also: → 1504787

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.

See Also: → 1545969
See Also: → 1565783
See Also: → 1558476
See Also: → 1563187

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.

Depends on: 1701846

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?

Flags: needinfo?(gijskruitbosch+bugs)

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

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

Flags: needinfo?(gijskruitbosch+bugs)

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

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3d3349b4a657
Allow users to enable overlay scrollbars on Linux from about:preferences. r=Gijs,fluent-reviewers,preferences-reviewers
https://hg.mozilla.org/integration/autoland/rev/8720b5f8902c
Enable GTK overlay scrollbars on Nightly and Early Beta. r=stransky
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b49c4d84f401
Disable overlay scrollbars for testing. r=jgraham

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

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox99: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch

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

Regressions: 1756831
No longer regressions: 1756831
Blocks: 1761690
Regressions: 1823418
Regressions: 1850075
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: