GNOME Bugzilla – Bug 734755
Mismatch between sidebar selection and content view / path bar
Last modified: 2021-06-18 15:49:29 UTC
If I select an item in the sidebar that cannot be displayed, or is in the process of being loaded, the path bar and content view don't update. For example: * Select an unmounted volume, then cancel the authentication dialog that pops up. The volume is still selected in the sidebar, yet the path bar and content view show the previous location. * Select a network location which you can't connect to. After a while, an error dialog pops up. After dismissing the dialog, the previous location is again displayed in the pathbar and content view, even though the location is still selected in the sidebar. To deal with this, we could: * Always make sure that the pathbar corresponds to the selected item in the sidebar. * Show a progress spinner in the content view if loading is taking a while. * Show an "unable to connect" or "volume not mounted" message in the content view, if the content of the location cannot be displayed.
3.14 is over - move to the 3.16 target milestone.
Created attachment 302672 [details] [review] window: set places sidebar to the previous location on error By using nautilus_window_slot_open_location, we're ignoring any error that can happen opening the location. This is needed in order to return to the previous location when an error happens. By exporting the display_view_selection_failure function, we can keep showing the error message related to the window slot.
Created attachment 302683 [details] [review] window: set places sidebar to the previous location on error By using nautilus_window_slot_open_location, we're ignoring any error that can happen opening the location. This is needed in order to return to the previous location when an error happens. By exporting the display_view_selection_failure function, we can keep showing the error message related to the window slot.
Review of attachment 302683 [details] [review]: The commit messages doesn't need to express every code change (like exposing some function or that we are going to use a different function). Also this part is not clear "This is needed in order to return to the previous location when an error happens." (where? I though Nautilus did something when an error happens! Ah, on the sidebar? ok =) ) Although the title of the commit message is clear. I would go with something like: title (this one is already good) (context) When gtk places sidebar reporterd a clciked location, we were opening that location on nautilus withouth further interaction with the sidebar. (what happens, the problem) The problem is, if a location cannot be loaded, the nautilus view fallback to a previous location, but since we weren't interacting anymore with the sidebar, the selected row on the sidebar was still the one that the user selected that cannot be loaded. (how you fix it) To fix it, set the previous location to the sidebar as well if there was some error on loading. ::: src/nautilus-window.c @@ +998,3 @@ + + if (error) { + gpointer user_data) old_file. Nautilus use "file" for NautilusFile and "location" for the GFile. Unfortunate, but better to keep the consistency.
Created attachment 302918 [details] [review] window: set places sidebar to the previous location on error Nautilus opened the location notified by GtkPlacesSidebar whithout too much interaction with it. With that, when a location fails to be opened, Nautilus goes back to the previous valid location but, because of the lack of interaction with the sidebar, it was not updated to match the location. To fix it, se the previous valid location to the sidebar as well if there's some error loading a location.
Review of attachment 302918 [details] [review]: The commit message is still a little confusing... "whithout too much interaction with it" what does that mean? not too much? See how I wrote before "we were opening that location on nautilus withouth further interaction with the sidebar" "but, because of the lack of interaction with the sidebar, it was not updated to match the location." what was not updated? to match the location of what? lack of interaction before or after or what do you mean? the wording is a little confusing. see how I wrote "but since we weren't interacting anymore with the sidebar, the selected row on the sidebar was still the one that the user selected that cannot be loaded." the last sentence looks fine. Code looks fine.
Created attachment 302945 [details] [review] window: set places sidebar to the previous location on error Actually, Nautilus opens the location notified by GtkPlacesSidebar without further interaction with it. With that, when a location fails to open, Nautilus goes back to the previous valid location but, because of we're not interacting with the sidebar after the failure, the sidebar was not updated to match these changes, i.e. kept the old invalid row selected. To fix it, set the previous valid location to the sidebar as well if there's some error loading a location.
Review of attachment 302945 [details] [review]: NOW!!! =D Delete the "Actually" In the first sentence tho. "Actually" here sounds incorrect. Be aware that the bug is not fixed, there are other issues Allan posted.
Comment on attachment 302945 [details] [review] window: set places sidebar to the previous location on error Attachment 302945 [details] pushed as 4059969 - window: set places sidebar to the previous location on error
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.