Apparently spurious allocation warnings cause GtkRange to misbehave
@kaiw
Submitted by Kai Willadsen Link to original bug (#770184)
Description
It appears that any change in child widget allocations to a GtkGrid subclass (except for those caused by top-level window resizes, etc.) put the widget into a state where some child widgets are considered to need resize calculations, but this state doesn't get cleared out.
In Meld, bug #770182 (triggered by having a read-only file that causes a toolbar button within the grid to be shown) reproduces this easily.
This results in warnings like: (meld:23742): Gtk-WARNING **: Allocating size to GtkVBox 0x55df7eaefa50 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
I've bisected the regression to commit 9a81e714.
I have no idea whether this commit is the actual cause, or whether it's hiding something deeper. It's also entirely possible that this is a bug in Meld's GtkGrid subclass, but given the commit message for the bisected commit, and the GtkCssGadget changes in 3.20, I thought it was reasonable to file this as a bug.
Also, quoting myself from bug #770182:
However, there is a more serious side-effect, which is that it (somehow, I have no idea how) causes some GtkRange manipulations in a container with a shared GtkGrid parent to do the wrong thing. I do appreciate how bizarre this sounds. My test case is to trigger this warning in Meld and then see GtkTextView.scroll_to_mark() calls silently fail to actually scroll the mark on-screen.
Version: 3.20.x