Search folders are not kept intact while they are part of the navigation history. (plus workaround)

[stabilergriller]

Hello,
This is all tested from the latest LM 21Cinnamon Live Image (linuxmint-21-iso-cinnamon-64bit.iso)

Issue

When leaving the Search Mode (for example by right-clicking on a file and pressing "Open containing folder") and returning to it afterwards, one lands in some unexpected, empty area. The previous search results seem to be lost. But there is some kind of weird workaround, that I really would love to see implemented as default behaviour.

Steps to reproduce

Open nemo and start searching for something (it does not matter where or what, but one should get at least one result)

Pick one random file, right-click on it and click on "Open containing folder"

You should now have left Search mode and be inside some regular folder

Now go back to the search, either by pressing the ALT + <- keys, or by clicking the "Go to the previous visited location" button, and you should end up here:

Expected behaviour

The previous search from Screenshot 2 should be restored. I don't want to do the whole typing and searching once again (since I maybe misclicked and now want to look at another file from the results list).

Other information

There is a fix, that I found by accident. Before clicking on "Open containing folder" on a file, one must right-click on the grey "Search in" area at the top and click on "Copy", and this somehow "remembers" the current search automatically and prevents to end up in the "Not supported in this location" / "No Files found" from Screenshot 5.

By doing this, you instead somehow cycle back to the search from Screenshot 2 (which is the behaviour that I would have expected).

May be related to this issue: Sometimes I also saw this in the Search area, which doesn't seem to be okay:

Issue #3104 may too be related to this, because there is also some weird behaviour with the Search area going on.

This also happens on other distrobutions, such as Arch + Budgie.

The easiest/best solution to this would be to unconditionally open containing folder in a new tab, and there should be a choice to open the tab in current pane, or second pane if enabled.
This way the search operation would in no way be disturbed, results would not be lost, search location would not be lost.

[SebiderSushi]

The easiest/best solution to this would be to unconditionally open containing folder in a new tab, and there should be a choice to open the tab in current pane, or second pane if enabled.

Remaining issue with that proposal is that after searching it's also possible to navigate to another directory using other means, e.g. via the sidebar or by entering a path. As a result, there are really only two options:

• Retain all information that is needed to restore the search. (This is what Nautilus does [tested with v43.1])
• Don't add searches to the history to begin with. Navigating back will jump to the directory where the search was initiated. (This is what Thunar does [tested with v4.18])

[mtwebster]

Navigating backward should restore the search parameters and results (without the search having to be performed again).

[Tibladar]

Tested: This still happens with Nemo 6.0 with Linux Mint 21.3

[Lanchon]

hey @mtwebster,

still happens on LM 22.1.

imho, this a big usability issue. it has been reported since 2017.

there are a few solutions available, some which require minimum effort:

• persist the search context (directory and query string) in the "back button" history stack.
  • also auto-restart the search when restoring a search context. (this is my preferred solution: it has a good balance of implementation complexity and usability. i prefer a good enough solution now, rather than a perfect solution in never ever land. it could be extended later if needed.)
  • alternatively, the saved search context could also include the results. this has drawbacks:
    • this goes against the current behavior of nemo, which is to reload the persisted context when hitting "back" (ie: refresh the folder contents), rather than showing an old snapshot of the contents of a stored context.
    • the result list size is unbounded and potentially very large, and could cause memory issues.
    • saving the results only if there are "few" of them is a workable solution. but it involves a new tunable parameter, for which people will undoubtedly ask for control. i suppose a simple dconf entry without UI would be enough.
      • if results are not saved because of size, a search auto-restart would be in order.

complementing the actions above, and especially if the search results are not included in history's search context, some additional changes should be considered:

• right now, (double-) clicking on a folder in nemo's file view will open the folder in the current tab. but if the clicking happens while holding down shift, the folder is opened in a new window. in search results, right-clicking on a file/folder and selecting "Open containing folder" is opening a folder, and as such it should have the same semantics: if the context menu item is selected while holding down shift, then the folder should be opened in a new window. this eases the problem of search results not being persisted.
• but opening in a new window is by no means always the preferable option. given that a "new window" shortcut is implemented, i do not see why a "new tab" shortcut is not. "new tab" should also be enabled in all folder opening contexts by some other shortcut, eg holding down control.
• (this might deserve a separate bug report.) there is a usability issue, where the "new window" shortcut is inconsistently implemented. while shift-clicking on a folder in the file list opens it in a new window, surprisingly control-clicking is needed to open a new window from the path "breadcrumbs" buttons above the file list. in either case, the other shortcut does nothing, so this is not a case of UI semantics clash.
  • imho, the semantics on both cases should be unified and extended to include a "new tab" shortcut.
  • due to the existing inconsistency and lack of dual shortcuts, there is the opportunity to redefine these shortcuts in the most sensible way for nemo. maybe we should look at nautilus, windows explorer, dolphin, thunar, etc, and copy the most established semantics if there are such.
    • nautilus: has no shortcuts, ignores both shift and control when double-clicking a folder in the file list.
    • thunar: same.
    • dolphin: unkown.
    • windows 11 23H2 explorer: control-click opens in new window (but half the time does not work). if multi-selecting folders, control-click open multiple new windows. shift-click is regular click, no shortcut for new tab. alt-click opens file properties.

[DukeofYore]

Tested - This still happens on Nemo 6.6.3 / Linux Mint 22.3