GNOME Bugzilla – Bug 765410
Scrollbar does not update since 3.20
Last modified: 2018-05-02 17:04:30 UTC
Since 3.20 the scrollbar in Geany[1] does not update (or only erratically). This only affects the editor widget. I bisected a possible commit, see at the end Perhaps this is specific how the editor widget works w.r.t. to scrolling. * The editor widget is a ScintillaObject type which is derived from GtkContainer. * The class installs a class handler for "scroll-event" signal. * Upon instantiation an explicit GtkScrollbar and GtkAdjustment are created * A handler is connected to the adjustment's "value-changed" signal The scoll-event handler calls ScrollTo(). That performs a redraw and then calls gtk_adjustment_set_value(). The value-changed handler also calls ScrollTo(). (possible recursion is handled in ScrollTo()). Debug prints show the GtkAdjustment is properly updated and ScrollTo() is properly called. However, the scrollbar does simply doesn't update. I bisected the following commits that are candidates: # possible first bad commit: [c1eff2cce5d2b870343f2d727b4a7d47519b78e4] range: deprecate more style properties # possible first bad commit: [413b9d5b3c10e9b296b09a99f34558d0bf36a72c] range: continue porting to GtkGadgets The first one couldn't be tested because it didn't show a scrollbar at all in my scenario. The other one is the first where the bug can be observed. I assume the second one is the problematic one. [1] Geany is a text editor and uses Scintilla as the editor component. Most of the code I talked about is here: https://github.com/geany/geany/blob/master/scintilla/gtk/ScintillaGTK.cxx. I tracked this issue for Geany here: https://github.com/geany/geany/issues/1002
How exactly can this be reproduced in geany? I've built the current git master version and scrolling seems to work, even though mouse wheel scrolling is inverted.
Here's a video showcasing the bug: https://oc.tmartitz.de/index.php/s/dRK2jWiKjuPlA70/download It doesn't seem to happen to all files opened in Geany. I can reliably reproduce it by opening gtkwindow.h from the gtk 3.20 source tree. The config with an otherwise empty, just gtkwindow.h in the saved session. When I restart Geany it automatically opens gtkwindow.h as well and scrolling is borked. In the video I've also got documentprivate.h open where this behavior can't be observed. This commandline also reproduces it for me: $PREFIX/bin/geany ../../gtk+.git/gtk/gtkwindow.h -c /dev/null Perhaps it also depends on the environment? I'm on KDE Plasma 5.6 currently, with kwin_x11 as the window manager.
One more thing: It happens regardless of the theme (I tried adwaita and arc).
I found a reliable way of reproducing this. In the “View” menu, toggling “Show Message Window” will fix horizontal scrollbar and break vertical scrollbar, I think because it changes the height only. “Show Sidebar” will have the reversed effect: fix vertical scrolling and break horizontal scrolling. I tested on current Geany master (a291a4239a656044f250dba5653fc3f4dac7bf9c) with an empty configuration (using 'geany -c /tmp/empty').
FWIW, this problem is also present in eog (and always reproducible here I think). Just load any larger image and use your mouse to zoom in. The sliders don't move. You can even drag them with the mouse and scroll that way, but the slider does not move. eog makes it easier to reproduce since you can just zoom out so the scrollbars are invisible and then scroll in again and observe the broken behavior again. I failed at writing a general reproducer for this, so I'm not sure what exactly is causing it but I thought about eog when I saw that geany is not using a GtkScrolledWindow. The problem as far as I can see is that in gtk_range_calc_slider() which we call from the value-changed handler, we call gtk_css_gadget_queue_allocate (priv->slider-gadget) -- which will simply become a gtk_widget_queue_allocate(range), but the range's size-allocate will not be called afterwards. Replacing this queue_allocate with a queue_resize works around the problem.
It happens in eog because it show()s the scrollbars in size-allocate; I'm not sure what geany/scintilla do. Benjamin wasn't able to tell me why the behavior changed so drastically from 3.18 to 3.20 though (probably because less widgets get resized now because we have gtk_widget_queue_allocate?)
I was wondering about adding this: diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c index 5b0e280..054c16a 100644 --- a/gtk/gtkwidget.c +++ b/gtk/gtkwidget.c @@ -6973,6 +6973,9 @@ gtk_widget_draw_internal (GtkWidget *widget, if (push_group) cairo_push_group (cr); + if (_gtk_widget_get_alloc_needed (widget)) + g_warning ("%s %p drawn with alloc_needed", G_OBJECT_TYPE_NAME (widget), widget); + if (g_signal_has_handler_pending (widget, widget_signals[DRAW], 0, FALSE)) { g_signal_emit (widget, widget_signals[DRAW], to catch the problematic situation when it happens. Is it ever ok to draw with alloc_needed ?
I don't think it is okay. We could certainly add the warning and see what happens. Just make the message not sound so internal.
ok, message added
Is this expected to be fixed? Can't seem to repro it with gtk 3.20.9
This commit seems related? commit 9a81e714d6acff1c9a489ffd461117db77de3521 Author: Matthias Clasen <mclasen@redhat.com> Date: Mon Jun 6 12:31:41 2016 -0400 range: Add a queue_resize call This is a workaround for a regression in updating scrollbars in some applications; notably eog. We haven't fully tracked down yet why a queue_allocation is not sufficient here, it should. diff --git a/gtk/gtkrange.c b/gtk/gtkrange.c index 8cbaf4f..b2e956c 100644 --- a/gtk/gtkrange.c +++ b/gtk/gtkrange.c @@ -3616,7 +3616,7 @@ gtk_range_calc_slider (GtkRange *range) gtk_css_gadget_set_visible (priv->slider_gadget, visible); - gtk_css_gadget_queue_allocate (priv->slider_gadget); + gtk_css_gadget_queue_resize (priv->slider_gadget); if (priv->has_origin) gtk_css_gadget_queue_allocate (priv->trough_gadget);
The problem here is that in all of the problematic cases, some widgets queues a resize (or allocate) during size allocation (or something else screws with the alocation flags GtkWidget has). It's basically the same problem that causes the "widget %p drawn without current allocation" warning. When queueing an allocate, the alloc_needed/alloc_needed_on_child flags are set immediately so we are kind of stuck in an undefined state and a) Once we call draw(), nothing reset them to FALSE (size-allocate is supposed to do that) so the warning about the missing current allocation is printed out and b) Even after draw() they are still set and conditions like https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c#n16216 check those flags and just abort when they are set Unfortunately, some of the widgets in GTK+ queue a resize/allocate during size-allocate and I don't know how to handle that case. (In reply to Thomas Martitz from comment #11) > This commit seems related? Yes, it's supposed to be a workaround.
I just have this bug happen on gtk 3.22.1. The workaround apparently isn't sufficient.
*** Bug 773610 has been marked as a duplicate of this bug. ***
The workaround made this indeed better after it got integrated in GTK+ 3.20.x (but there was still a race condition) and with GTK+ 3.22.x it seems the workaround does not work anymore (for example scrollbars in SciTE now don't visually update anymore at all). This issue has a high impact on usage/productivity on affected applications (for example I have now to downgrade to an older version of GTK+ and pin it to be able to continue developing). Hopefully this issues doesn't last for too long as pinning could cause another issues in the long term. Or shall I just forward this issue directly downstream?
*** Bug 771899 has been marked as a duplicate of this bug. ***
gnome-terminal also suffers from this bug, see the just-marked duplicate issue.
(In reply to sworddragon2 from comment #15) > The workaround made this indeed better after it got integrated in GTK+ > 3.20.x (but there was still a race condition) and with GTK+ 3.22.x it seems > the workaround does not work anymore (for example scrollbars in SciTE now > don't visually update anymore at all). Looking at the gtk-3-22 branch it seems the workaround is not part of 3.22 so far. ;-) The commit given in comment 11 applies cleanly to gtk-3-22 though and produces "working" (considering it's just a workaround) scrollbars with 3.22 again. Is it okay to push it to gtk-3-22 as well?
*** Bug 774661 has been marked as a duplicate of this bug. ***
I have been having a losing fight with scrollbars. Here are my observations I have widget (a list in this case) which i fill. I then save position of scrollbar. Shut down and restart. Reload list... then try and reset scrollbar using gtk_adjustment_set_value. If all cells are not the same height this fails and the bar is only partially set.
Gtk 3.22.1 but pretty sure this has been the case for 3.20 as well Works fine on gtk2 :P
Is there an answer to the question from comment 18 about Matthias' prior workaround commit? It seems odd that the fix/workaround would only exist in the 3.20 branch. It would be one thing if it had been later reverted, but it was just apparently applied directly to the 3.20 branch and never to any other. It would also make sense if the problem had been solved in a more fundamental way, but that doesn't seem to be the case.
Pushed to gtk-3-22: https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=09b2c54d41b4d2f8cd2f58f0e1a7c8e6246623dd > It would also make sense if the problem had been solved in a more fundamental > way, but that doesn't seem to be the case. That was the reasoning behind not pushing it to the back-then-master, but nobody stepped up to fix the deeper issue. Not pushing to gtk-3-22 afterwards was just an oversight.
This bug still happens with gtk 3.24, so I'm assuming the patch was not applied to 3.24 either. I can reproduce it 100% with the Howl editor.
(In reply to Otto Robba from comment #24) > This bug still happens with gtk 3.24, so I'm assuming the patch was not > applied to 3.24 either. > > I can reproduce it 100% with the Howl editor. *3.22.12
There is no GTK+ 3.24; it's still 3.22 which has this patch.
Friendly ping... The "workaround" made it into Gtk+ 3.22.8. On Ubuntu Artful beta (Gtk+ 3.22.21) the scrollbar is still positioned incorrectly if I scroll with Shift+Page{Up,Down} in gnome-terminal. Other folks have also reported that the problem still persists in other apps. This is a terrible user experience that has been present for almost a year and a half now. Could you guys who are familiar with Gtk+ please give this bug a bit more love and care? Thanks in advance!
Gnumeric appears to be affected too, see bug 789412.
I don't know anything about a problem with Shift-PageUp scrolling in gnome-terminal. It appears to work perfectly fine here. Please don't conflate random issues, it only makes bugs unfixable and unclosable.
(In reply to Matthias Clasen from comment #29) > I don't know anything about a problem with Shift-PageUp scrolling in > gnome-terminal. It appears to work perfectly fine here. Pretty broken here. Not on each and every Shift-PageUp keypress, but most often than not, easily reproducible in a few seconds. I'm absolutely sure that there were no relevant changes in gnome-terminal when it started to happen. I updated my entire distro then except for VTE and gnome-terminal (as I use them from git master). (Of course this doesn't exclude the possibility that VTE or gnome-terminal is doing something wrong and a change in GTK+ just happened to bring it to the surface.) > Please don't conflate random issues, it only makes bugs unfixable and > unclosable. Only in this very bugreport, 4 different GTK+-based apps were mentioned to suffer from the same symptoms, so IMO it's reasonable to suspect that most likely the same underlying GTK+ issue causes them, isn't it? Tell me please: what's your preferred way of dealing with such situations? A separate bugreport for each affected application? If so, I'll happily undup the gnome-terminal one and reassign to GTK+. Thanks!
This bug report started out as a bug about scrollbars not updating. This was worked around long ago. People just keep piling on with 'me too' style comments without even describing the symptoms they are considering 'the same'. The most concrete you gave me is 'scrollbar positioned incorrectly'. Its just not the same as 'does not update at all' which is where this bug started out. In cases like that, I will quickly try to reproduce (and for me, Shift-PageUp/Down appears to work fine), and move on, since it just takes too much time to sort about 20 vague 'me toos'. Sorry
No worries, thanks for the explanation and sorry for the false dup!
For the record, the Gnumeric problem relayed in comment 28 is that scroll bars fail to update. Attachment 362189 [details] has a screen shot to that effect. I have requested more version info, but a guess suggests that it is stock OpenSuSE with gtk+ 3.20.10.
(In reply to Matthias Clasen from comment #31) > This bug report started out as a bug about scrollbars not updating. This was > worked around long ago. But unfortunately the workaround does not fully fix the issue and I'm still hoping that the real cause of the initial bug will be figured out and fixed at some point. (In reply to Matthias Clasen from comment #31) > The most concrete you gave me is 'scrollbar positioned incorrectly'. Its > just not the same as 'does not update at all' which is where this bug > started out. It depends, because even with the workaround the scrollbars do sometimes not update and thus making them visually appear at the wrong position while they technically aren't.
Edit: The last was to be mentioned generic, not specific to the Gnumeric issue.
Confirmed bad (i.e., scroll bar not updating) with Gtk+ 3.22.25 using Gnumeric. Instructions to reproduce in bug 789412.
I still see this in the text editor SciTE (which uses Scintilla underneath), GTK 3.22.24, on Debian unstable, which seems to already have the workaround replacing gtk_css_gadget_queue_allocate with gtk_css_gadget_queue_resize I have uploaded a webm showing the problem to my homepage (about 6mb): http://www.gusnan.se/scite/SciTE.webm The video illustrates me starting SciTE, scrolling using the mousewheel (Notice that the scrollbar doesn't move, but the scroll buttons does change depending on me being on the top of the document or the bottom). Then I press the left mouse button on the document, and do some more scrolling and now the scrollbar updates as it should. In addition to this it seems like if I start SciTE opening a document, and press PgDown the first thing I do, the scrollbar won't react on the first keypress, but will on any additional keypresses.
Jean Brefort came up with a workaround for Gnumeric. I mention this here because it might shed light on the underlying problem. Before the workaround, we had a size-allocate handler on the scroll bar. The handler can be seen at https://git.gnome.org/browse/gnumeric/tree/src/sheet-control-gui.c#n476 After the workaround, the size-allocator instead installs a timeout to get the real work done: g_timeout_add (1, (GSourceFunc) scg_scrollbar_config_real, (gpointer)sc);
I can chime in from the perspective of the Howl editor, which is/was also affected by this behaviour. The basic widget structure here is a GtkBox containing a custom drawing area and separate scrollbars. The scrollbars were at first updated in the size allocate handler for the drawing area, which worked fine but caused Gtk warnings about not knowing the size to allocate. After changing this to use a size allocate handler for the parent GtkBox, the warnings disappeared but instead I got the buggy behaviour described by some above. When I looked at it it appeared that of all the requests to reconfigure the scrollbar adjustments only some would actually take effect visually, meaning scrollbars would incorrectly remain at old locations. At the time I also had to resort to the ugly hack of postponing scrollbar syncing via a timeout, which is currently in place: https://github.com/howl-editor/howl/commit/e83e98ee5e9e90286636bb753c85ddd887ba268c. However, at the time of the investigation I also noticed that I got what appeared to be spurious on-size-allocate callbacks, e.g. where the allocated geometry hadn't changed since the last call, and I added a guard for this to prevent unnecessary updating. Just recently I had cause to muck around in this area again, and noticed that as long as I have the spurious callback guard in place I don't actually have to use a timer but can update the scrollbars directly. This is with library versions as of Ubuntu 17.10 however - I haven't yet had time to check whether this will work with all the older versions.
Just to follow up on my last comment, I have now checked against Ubuntu 12.04 and 14.04 as well and updating scrollbars from the size allocate handler works well when geometry has actually changed.
I think a contributing cause of the problem might be that gtk_adjustment_configure seems to fire off signals even when nothing whatsoever is being changed. Specifically: if (old_stamp == adjustment_changed_stamp) emit_changed (adjustment); /* force emission before ::value-changed */ That code isn't new, though.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/615.