[GTK3] Implement overlay scrollbars
Categories
(Core :: Widget: Gtk, enhancement, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: stransky, Assigned: emilio)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
(Whiteboard: tpi:+)
Attachments
(5 files)
Comment 1•10 years ago
|
||
Updated•9 years ago
|
Comment 4•9 years ago
|
||
Comment 5•9 years ago
|
||
Comment 6•9 years ago
|
||
Updated•8 years ago
|
Updated•8 years ago
|
Comment 9•8 years ago
|
||
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
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.
Comment 14•4 years ago
|
||
How is this going to be handled with NNT?
Assignee | ||
Comment 15•4 years ago
|
||
Overlay scrollbars should already work if you create the ui.useOverlayScrollbars
and set it to 1
, I'd think.
Comment 16•4 years ago
|
||
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…).
Assignee | ||
Comment 17•4 years ago
|
||
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.
Comment 18•4 years ago
•
|
||
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.
Assignee | ||
Comment 19•4 years ago
|
||
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.
Comment 20•4 years ago
|
||
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.
Comment 21•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)
Overlay scrollbars should already work if you create the
ui.useOverlayScrollbars
and set it to1
, I'd think.
Pardon my curiosity. Any particular reason why that about:config entry needs to be of type number?
Comment 22•4 years ago
|
||
(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.
Comment 23•4 years ago
|
||
(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 toFALSE
.The user/environment can request permanent scrollbars by setting the
gtk-overlay-scrolling
global setting toFALSE
, 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
Comment 24•4 years ago
|
||
(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 toFALSE
.The user/environment can request permanent scrollbars by setting the
gtk-overlay-scrolling
global setting toFALSE
, 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.
Assignee | ||
Comment 25•4 years ago
|
||
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.
Comment 26•3 years ago
|
||
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.
Comment 27•3 years ago
|
||
They seem to work pretty well. Is there no desire to enable them by default?
Assignee | ||
Comment 28•3 years ago
|
||
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.
Assignee | ||
Comment 29•3 years ago
|
||
If there is no GTK setting, perhaps we should expose this in about:preferences
(probably near autoscroll and such). Gijs, would that be reasonable?
Comment 30•3 years ago
•
|
||
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.
Assignee | ||
Comment 31•3 years ago
|
||
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
(triedgnome-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.
Comment 32•3 years ago
|
||
You can find the setting with dconf-editor
, searching for overlay-scrolling
.
Assignee | ||
Comment 33•3 years ago
|
||
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.
Updated•3 years ago
|
Assignee | ||
Comment 34•3 years ago
|
||
Let's try.
Depends on D138502
Assignee | ||
Comment 35•3 years ago
|
||
(In reply to Jan Alexander Steffens [:heftig] from comment #32)
You can find the setting with
dconf-editor
, searching foroverlay-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 :)
Assignee | ||
Comment 36•3 years ago
|
||
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.
Assignee | ||
Comment 37•3 years ago
|
||
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.
Comment 39•3 years ago
|
||
(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.
Assignee | ||
Comment 40•3 years ago
|
||
(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.
Comment 41•3 years ago
|
||
Comment 42•3 years ago
|
||
Comment 43•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3d3349b4a657
https://hg.mozilla.org/mozilla-central/rev/8720b5f8902c
https://hg.mozilla.org/mozilla-central/rev/b49c4d84f401
Comment 44•3 years ago
|
||
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.
Assignee | ||
Comment 45•3 years ago
|
||
(In reply to gwarser from comment #44)
Created attachment 9263944 [details]
GIF 2022-02-15 14-41-38.gifSo, 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.
Comment 46•3 years ago
|
||
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.
Assignee | ||
Comment 47•3 years ago
|
||
(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.
Comment 48•3 years ago
|
||
Hi thanks see my report here https://bugzilla.mozilla.org/show_bug.cgi?id=1756831
Description
•