Possible refcounting bug around GtkListbox signal handlers
See https://git.gnome.org/browse/gnome-weather/commit/?id=44ed7a29bbd3a491c8ad3cd49b76870d728dfa60
The issue is, the old code would touch "row._info" after calling moveLocationToFront(). moveLocationToFront() modifies the GListModel of the GtkListBox, causing it to remove the GtkListBoxRow (row) and add a new one. With the old code, gjs complains that "row" has been finalized, and properties cannot be accessed on it.
Because the JS object wrapping the GtkListBoxRow is clearly alive (it's a local variable on the stack), there is no way the GtkListBoxRow should be finalized. At most disposed, but that should not affect JS properties on the wrapper (like "_info" in this case). Which makes me think that something, somewhere, is unreffing the GtkListBoxRow too eagerly.
Not sure if this is a bug in gjs or in the gtk introspection metadata, but because this bug occurs with a GObject and signals, which should be kept safe by GType's memory management, I suspect a bug in gjs.
This bug did not occur with last cycle's gjs (GNOME 3.26)