GNOME Bugzilla – Bug 563009
path bar screws up back/forward history
Last modified: 2017-10-25 23:50:20 UTC
Please describe the problem: Navigating using the back/forward buttons becomes unpredictable in certain circumstances after navigating using the path bar. Steps to reproduce: 1. run 'nautilus /usr/share/nautilus/' 2. click 'share' in the path bar 3. click 'nautilus' in the path bar 4. click the Back button Actual results: Back button is disabled, so nothing happens. Expected results: Back button is enabled and returns me to /usr/share, since that's the last place I was. Does this happen every time? This happens every time. Other information: As well as causing the back button to be disabled when I think it should work (this was the simplest demonstration I could come up with), this issue can cause the Back button to take you to an unexpected folder (i.e. not the last one you were looking at)
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/362112 details another aspect of this general bug.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 557462 ***
Sebastien, I don't think this is a duplicate of 557462... That one appears to be purely that selections are not remembered when returning to a folder. This is about the path bar not interacting sensibly with the history of viewed folders, making the back/forward buttons do unexpected things. I'm going to re-open this, because although that bug references this one they're very different issues.
Confirming.
Changing component as part of ongoing bug reorganisation work.
Created attachment 177645 [details] [review] Fix the interaction between back/forward history and path bar Don't adjust the behavior of back/forward history if the target location of the path bar was already visited. After navigating using the path bar navigating using the back/forward buttons behaves unusually if the target location of the path bar was already visited. Therefore it becomes unpredictable for some users.
(In reply to comment #6) > Created an attachment (id=177645) [details] [review] > Fix the interaction between back/forward history and path bar > > Don't adjust the behavior of back/forward history if the target location > of the path bar was already visited. > > After navigating using the path bar navigating using the back/forward > buttons behaves unusually if the target location of the path bar was > already visited. Therefore it becomes unpredictable for some users. Marcus, thanks for the patch. The code itself would look fine, but I must say that I don't like the new behavior as well. I think ideally we should follow these principles for back/forward buttons: - forward button should only be used in case back was explicitly used before. - if a click on a pathbar button goes to the same directory as it would by clicking 'Back', or 'Forward', (i.e. to one of the two topmost items in history) then we should treat that as a history action. - we should never have duplicate entries in the history list. - back history should be cleaned only when closing a window. - forward history should be cleaned every time we go to a directory as a result of something different from a click on a 'Back' item. Allan, what do you think?
Hi there, is this still a problem with the latest version?
Yes, I can reproduce it in nautilus 3.10, as described on comment 0.
(In reply to Cosimo Cecchi from comment #7) > - if a click on a pathbar button goes to the same directory as it would by > clicking 'Back', or 'Forward', (i.e. to one of the two topmost items in > history) then we should treat that as a history action. This is exactly what this bug report is about. This behaviour is the "bug" being reported. We need a decision here: if this behavior is intentional by design, please mark this a a WONTFIX and reject the patch. (Although I personally dislike this behavior.)
Created attachment 357870 [details] [review] window: Make history-hierarchy interaction orthogonal. Forward-porting original patch. After discussing it with Carlos on IRC, a linear history is preferred. The patch works as expected so we can fix this bug.
Review of attachment 357870 [details] [review]: ::: src/nautilus-window.c @@ +1942,2 @@ priv = nautilus_window_get_instance_private (window); + nautilus_window_open_location_full (window, location, 0, NULL, NULL); priv is no longer used, I got a warning while compiling
Created attachment 357874 [details] [review] window: Make history-hierarchy interaction orthogonal. Sorry, forgot to look at the warnings. Fixed.
Review of attachment 357874 [details] [review]: Looks good now, thanks!
Attachment 357874 [details] pushed as 017a90b - window: Make history-hierarchy interaction orthogonal.
*** Bug 605615 has been marked as a duplicate of this bug. ***