diff options
| author | Carlos Soriano <csoriano@gnome.org> | 2016-04-14 14:57:04 +0200 |
|---|---|---|
| committer | Carlos Soriano <csoriano@gnome.org> | 2016-04-14 17:53:32 +0200 |
| commit | 035cd2db2d10c0194b74eb87ce337a775f7e49bb (patch) | |
| tree | d7f80a671ceb269c1ca52b9676e2c3c5215b80e7 | |
| parent | 66c17fa53d0afe1adfcc976d4d5ba52a6c3dc3f3 (diff) | |
| download | nautilus-035cd2db2d10c0194b74eb87ce337a775f7e49bb.tar.gz | |
window-slot: fix condition for disconnecting old view
We were checking for the new view instead of the old view...
Needless to say that's wrong, and we were not disconnecting at all.
It was not crashing because the view is disconnected when is going to be
destroyed, so no more signals are done.
However, when we were destroying the view, the view signals the
end-loading signal, which forces the slot to free any change data, in
middle of a change.
"Luckely" thanks to all the safe checks in window slot, this was not
crashing, but just misbehaving and not updating the window with the new
view data.
https://bugzilla.gnome.org/show_bug.cgi?id=764981
| -rw-r--r-- | src/nautilus-window-slot.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/nautilus-window-slot.c b/src/nautilus-window-slot.c index 778642703..9eeafba70 100644 --- a/src/nautilus-window-slot.c +++ b/src/nautilus-window-slot.c @@ -2268,7 +2268,7 @@ nautilus_window_slot_disconnect_content_view (NautilusWindowSlot *self) NautilusWindowSlotPrivate *priv; priv = nautilus_window_slot_get_instance_private (self); - if (priv->new_content_view && NAUTILUS_IS_FILES_VIEW (priv->new_content_view)) { + if (priv->content_view) { /* disconnect old view */ g_signal_handlers_disconnect_by_func (priv->content_view, G_CALLBACK (view_is_loading_changed_cb), |