After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781807 - Where is the scroll bar?
Where is the scroll bar?
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-04-27 00:41 UTC by Chuck Pergiel
Modified: 2017-06-17 08:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chuck Pergiel 2017-04-27 00:41:22 UTC
The scroll bar keeps disappearing in every editor. I use it to figure out where I am in a file. I move to a new place in a file to look at something, and when I look back to where the scroll bar should be so I can figure out where I am and the stupid thing has disappeared. And why is it so skinny? If it was just a few pixels wider it would be easier to grab. Yes, I know, everyone wants to do something new and cool, but this skinny, disappearing scroll bar really bugs me.
Comment 1 Ray Strode [halfline] 2017-04-27 18:09:41 UTC
I'm assuming you meant to file this against gtk+ from comment 0 and not gdm.  The former is the toolkit that provides scrollbars for editor applications.  The latter is a backend daemon used for providing login functionality.

I believe there are legitimate reasons the gtk+ scrollbar design has evolved to its current state, so I doubt it will get changed back by default.
Having said that, I think you can alter the behavior to match a more traditional model by setting GTK_OVERLAY_SCROLLING=0 in /etc/environment.
Comment 2 Felix Miata 2017-04-27 23:34:59 UTC
(In reply to Ray Strode [halfline] from comment #1)
> Having said that, I think you can alter the behavior to match a more
> traditional model by setting GTK_OVERLAY_SCROLLING=0 in /etc/environment.

I tried that with Firefox 53.0 in KDE3 on openSUSE Tumbleweed with GTK 3.22. It has no effect. The visible target and the stepper buttons are much too narrow for those of us with >96 DPI displays, tired old eyes, and glitchy fingers and/or wrists.
Comment 3 Matthias Clasen 2017-05-01 16:10:10 UTC
firefox does its own things. GTK+ is not responsible for what firefox does or doesn't do, theme-wise.
Comment 4 Felix Miata 2017-06-17 08:18:07 UTC
(In reply to Matthias Clasen from comment #3)
> firefox does its own things. GTK+ is not responsible for what firefox does
> or doesn't do, theme-wise.

That's not entirely true (and what I wrote in comment 2 applies to SeaMonkey as well). See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 (can't fix?)
which is blocked by 
WONTFIX https://bugzilla.gnome.org/show_bug.cgi?id=757142

Life for us non-96DPI QT users worked passably until Mozilla.org switched from GTK2 to GTK3.