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.