GNOME Bugzilla – Bug 721194
Back (return to overview) button not working after closing search bar in preview
Last modified: 2014-01-08 17:56:14 UTC
After going through the following steps, the Back button in preview is no longer working: 1. Use search bar in overview to search for some document. 2. Click on (i.e. preview) one of the documents that match the search pattern. 3. In preview, search bar will be visible. Close it. 4. Try to go back to overview by clicking the Back button. Actual behaviour: clicking on Back button has no effect. Expected behaviour: clicking on Back button should take you back to overview of the documents.
Amazing, who knew! Thanks for the details on how to reproduce it.
This is somewhat similar to bug 701252 1. For some reason the OverviewSearchbar is not destroyed when we move from OVERVIEW to PREVIEW. As far as I can make out the 'destroy' signal is never emitted, but it appears as if a new object is created every time the mode is changed. I do not know what is going on there. Looking at _prepareForOverview and _prepareForPreview, the old toolbar should be destroyed when it is replaced with a new one. Maybe we need to explicitly destroy it? 2. Since the OverviewSearchbar is still around in PREVIEW, its entryChanged is called when we toggle the search button to hide the searchbar. 3. That causes TrackerController to react to 'search-string-changed' which eventually leads to clearing the DocumentManager. 4. Therefore, when you hit the back button to go back to OVERVIEW, the active item is already NULL, and again setting it to NULL does not emit 'active-changed'.
Created attachment 265128 [details] [review] searchbar: Disable entryChanged when not in the overview This does not look right to me because the OverviewSearchbar should not around when we are not in OVERVIEW.
Created attachment 265129 [details] [review] embed: Ensure that the old toolbar is destroyed when changing modes This is another way to fix it by ensuring that the older toolbars are destroyed. This would also fix bug 721165
Created attachment 265706 [details] [review] embed: Ensure that the old toolbar is destroyed when changing modes This is actually a regression from 65e878570d44638812d346a5db0cf3bfd7589e7d
*** Bug 721165 has been marked as a duplicate of this bug. ***
Review of attachment 265706 [details] [review]: I thought calling set_titlebar() again would destroy the original toolbar? Maybe we're keeping a reference to it from JS and that causes the widget not to be garbage collected immediately. In any case, this looks good to me.
(In reply to comment #7) > Review of attachment 265706 [details] [review]: > > I thought calling set_titlebar() again would destroy the original toolbar? > Maybe we're keeping a reference to it from JS and that causes the widget not to > be garbage collected immediately. Yeah, that is what I had assumed initially. Apparently not. :(
Comment on attachment 265706 [details] [review] embed: Ensure that the old toolbar is destroyed when changing modes Thanks for the review!