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 :)

See also bug 791968 comment 9.

Not sure if bug 765700 is any relevant or helpful for us.

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.

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.

Observations:

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.

Theory:

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.

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 ***