GNOME Bugzilla – Bug 769498
Scrollbars are broken
Last modified: 2016-10-28 01:56:19 UTC
After upgrading from GTK+ version 3.18.9 to version 3.20.6 I'm noticing some issues with scrollbars: - Scrollbars do not update in some applications anymore. They will always keep the same visual state (like in Eye of GNOME and SciTE but not in Firefox) and sometimes this is not limited to the visual state (in SciTE I can't scroll vertically anymore on dragging the scrollbar). - If the steppers are enabled the arrows on them are drawn on the vertical steppers but not on the horizontal steppers in some applications (like Eye of GNOME and SciTE but not in Firefox). - The default background color of the steppers is the same like the scrollbars in some applications (like Eye of GNOME and SciTE but not in Firefox) and hovering effects do not change the background color (seems to happen in all applications). - In Firefox I'm also noticing a case where a scrollbar of a div-container forced to appear with "overflow-y: scroll;" does not visually appear on initialization but the steppers appear as soon as the window gets shrinked enough (they are still there on reverting the resized state but the scrollbar itself is always invisible).
Which theme are you talking about ? The mention of steppers makes it seem likely that it is not Adwaita
It is Adwaita and the steppers are enabled because -GtkScrollbar-has-backward-stepper and -GtkScrollbar-has-forward-stepper are set to true.
For a bug about not-updating scrollbars (and possibly the other issuse in eog/scite as well), see https://bugzilla.gnome.org/show_bug.cgi?id=765410
Oh and there's also a workaround for this in gtk-3-20: https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-20&id=9a81e714d6acff1c9a489ffd461117db77de3521 but unreleased so far.
Now released in 3.20.8
The first point in the startpost is indeed better now after upgrading to GTK+ 3.20.8 as only the vertical scrollbar in SciTE does not initialize correctly which corrects after affecting it (like dragging it) but all other 3 behaviors do still exist.
Let's try this again then... > - Scrollbars do not update in some applications anymore. They will always > keep the same visual state (like in Eye of GNOME and SciTE but not in > Firefox) and sometimes this is not limited to the visual state (in SciTE I > can't scroll vertically anymore on dragging the scrollbar). > - If the steppers are enabled the arrows on them are drawn on the vertical > steppers but not on the horizontal steppers in some applications (like Eye > of GNOME and SciTE but not in Firefox). Can reproduce in gtk3-widget-factory. They are indeed just not drawn (or overdrawn by the trough maybe?) but can be clicked on and the size request seems to match. Just for reference so I don't have to write this all the time (or cosimo if I can convince him to look into this... :): * { -GtkScrollbar-has-forward-stepper: 1; -GtkScrollbar-has-backward-stepper: 1; } scrollbar contents button { min-width: 50px; min-height: 50px; } > - The default background color of the steppers is the same like the > scrollbars in some applications (like Eye of GNOME and SciTE but not in > Firefox) and hovering effects do not change the background color (seems to > happen in all applications). So that's just a theming issue? I assume firefox does something custom if they are different there. And since the foreground color changes just fine I think this is a case for lapo? > - In Firefox I'm also noticing a case where a scrollbar of a div-container > forced to appear with "overflow-y: scroll;" does not visually appear on > initialization but the steppers appear as soon as the window gets shrinked > enough (they are still there on reverting the resized state but the > scrollbar itself is always invisible). Sorry but what firefox exactly does when you resize a div with overflow-y: scroll; is just out of anyone's reach, that needs a minimal testcase.
Created attachment 333939 [details] [review] range: Set stepper style classes according to orientation Turns out the horizontal steppers still get .up/.down style classes applies which makes them not show up in the UI at all. I'm not sure if this is intentional at this point but here's a patch for changing it. With this applied, the horizontal ones still look different than the vertical ones but I'm not sure if that's a theme issue or not.
(In reply to Timm Bäder from comment #7) > So that's just a theming issue? I assume firefox does something custom if > they are different there. And since the foreground color changes just fine I > think this is a case for lapo? Just a guess: From GTK+ version 3.18.9 to version 3.20.8 the selector has changed from the class selector .scrollbar to the element selector scrollbar. Maybe some parts have been overlooked and are still using the class selector while they should use the element selector? (In reply to Timm Bäder from comment #7) > Sorry but what firefox exactly does when you resize a div with overflow-y: > scroll; is just out of anyone's reach, that needs a minimal testcase. I'm noticing that the scrollbar does now appear without resizing (maybe I hit just a race-condition or whatever). The main issue seems to be that in-site scrollbars have a white (or maybe transparent) background and this issue gets especially obvious if an element forces to show a scrollbar while where is nothing to scroll as only the steppers are then visible. Also I have noticed an additional issue with Firefox. On the main scrollbar at the right the most right pixel seems to cause to loose the visual hovering effect for the scrollbar but you can still drag it with the mouse.
(In reply to Timm Bäder from comment #8) > Created attachment 333939 [details] [review] [review] > range: Set stepper style classes according to orientation > > Turns out the horizontal steppers still get .up/.down style classes applies > which makes them not show up in the UI at all. I'm not sure if this is > intentional at this point but here's a patch for changing it. With this > applied, the horizontal ones still look different than the vertical ones but > I'm not sure if that's a theme issue or not. How does it make them not show up ? I do think the classes were intentional as-is, so I'd like to figure out why this is happening before changing the style classes
(In reply to Matthias Clasen from comment #10) > How does it make them not show up ? I do think the classes were intentional > as-is, so I'd like to figure out why this is happening before changing the > style classes From staring at the inspector, it looks like it switches the icon source to builtin (which is why they look different now) while before it's -gtk-icontheme("pan-right-symbolic") for example. A quick check in my local adwaita-icon-theme checkout doesn't bring up any references to pan-left-symoblic/pan-right-symbolic while the up/down variants exist. Missing icon?
Created attachment 333985 [details] [review] Adwaita,HC: fix icon name - while we don't use steppers anymore, for some reason they are still defined in the theme and if you sacrifice a chicken and jump on one leg at full moon, you can enable them.
Review of attachment 333985 [details] [review]: I sooo want to see you do that ritual next guadec
Review of attachment 333939 [details] [review]: Don't need this then.
Is the target milestone version 3.20.10? As it seems there are still unhandled regressions in this ticket. Shall I forward specific ones like the transparent scrollbars in Firefox to their related tracker?
With GTK+ 3.22.2 the second issue is indeed fixed but all the other issues do still exist and I have created now own tickets for them.