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 791014 - gnome-terminal: warning when maximising/unmaximising: Allocating size to GtkScrollbar 0x5576e3a8cb90 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
gnome-terminal: warning when maximising/unmaximising: Allocating size to GtkS...
Status: RESOLVED DUPLICATE of bug 769566
Product: gnome-terminal
Classification: Core
Component: general
Other Linux
: Normal minor
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Reported: 2017-11-30 09:57 UTC by Paul Wise
Modified: 2018-02-08 21:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Paul Wise 2017-11-30 09:57:57 UTC
Whenever I maximise or unmaximise gnome-terminal 3.26.2-1 on GNOME 3.26 on Debian buster I get a warning like this in my journal:

Nov 30 17:53:57 chianamo gnome-terminal-[415]: Allocating size to GtkScrollbar 0x5576e3a8cb90 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Comment 1 Egmont Koblinger 2017-11-30 13:41:25 UTC
We already wanted to track this down (mentioned this in e.g. bug 771899 and bug 781479 comment 72 - not sure if the warning is related to the actual faulty behaviors there) but we never got around to file a separate bug for this. So here it is, thanks :)
Comment 2 Egmont Koblinger 2017-12-28 22:48:22 UTC
See also bug 791968 comment 9.
Comment 3 Egmont Koblinger 2018-02-08 11:30:40 UTC
Not sure if bug 765700 is any relevant or helpful for us.
Comment 4 Egmont Koblinger 2018-02-08 12:03:44 UTC
It's GtkScrollbar that emits the warning. GTK+ GtkScrollbar bug is bug 769566.

Looks like all VTE-based apps suffer from this problem, if they have a scrollbar. Tilix only if Preferences -> Appearance -> Use overlay scrollbars is disabled.

In the spirit of the recent fix to bug 771899 [VTE scrollbar update delayed] I suspect that VTE still doesn't do everything exactly as desired, which leads to GtkScrollbar getting a bit confused.
Comment 5 Egmont Koblinger 2018-02-08 12:36:38 UTC
In VTE-based apps that don't install geometry hints, the warning is printed exactly when the height measured in characters changes. So it's definitely related to something that VTE knows about / VTE updates in these cases.
Comment 6 Egmont Koblinger 2018-02-08 14:49:10 UTC

Our entry point for resize is widget_size_allocate(). This in turn calls set_size(). This calls two relevant methods: set_scrollback_lines() and adjust_adjustments_full(). The former one is only relevant because it also calls adjust_adjustments_full() so we arrive at this method via two call paths.

adjust_adjustments_full() first calls adjust_adjustments() which is harmless becauses is asynchronous (just queues the change). Then it skips calling gtk_adjustment_set_step_increment() because its value never changes. Then it calls gtk_adjustment_set_page_size() and gtk_adjustment_set_page_increment().

These latter two are the methods that trigger the warning. Removing both of them makes the warning go away. Removing them but adding a synchronous variant of adjust_adjustments(), that is, gtk_adjustment_set_value() also triggers the warning.


When the window height changes, GTK+ calls size_allocate for both VTE and the Scrollbar "in parallel". VTE handling this event also causes synchronous changes to the Adjustment (and in turn to the Scrollbar). That is, the Scrollbar receives changes both from the bottom (GTK+) and sideways (VTE) at the "same time". It looks to me that this is what Scrollbar doesn't like.

We'd need input from a GTK+ expert whether this is really a sufficient reason for Scrollbar to warn and is really something we should avoid, or whether not being able to handle this is a bug in Scrollbar.

A solution/workaround from VTE could be to defer these gtk_adjustment_set_whatever() calls to when idle.

Let's mention long-pending bug 709089 which is of the opposite direction: in some cases we adjust the adjustment asynchronously whereas we could/should do synchronously. Apparently here we'd need to turn it from sync to async.

Yet another observation:

xfce4-terminal allows you to place the scrollbar on the left. The warning doesn't appear in that case. Debugging both VTE and GTK+ reveals that indeed size_allocate is called on the left widget first, then on the right. Apparently in the "scrollbar on the left" case it has already settled with the new allocation when VTE pokes it, so it's okay.
Comment 7 Egmont Koblinger 2018-02-08 21:19:41 UTC
I'm pretty sure now it's a GTK+ bug. I have a tiny, VTE-free test case that reproduces the warning.

Let's mark as duplicate to keep the investigation at one place.

*** This bug has been marked as a duplicate of bug 769566 ***