GNOME Bugzilla – Bug 764981
Selection a directory from search results directly with 'Enter' doesn't change Location Bar
Last modified: 2017-07-14 11:44:53 UTC
Hello! The new Typeahead (Search in Subfolder -> never) or Find in Nautilus is awesome. A problem occurs if a search result it directly selected from the prompt with enter, the Location Bar stays in the search mode. So the user can't see what is the current working-directory (CWD). Assume you are in your home-directory (~) and you want change into the subdirectory 'Pictures': 1. Just type 'pictures' # the directory 'Pictures' should be marked 2. Hit 'Enter' # don't tab to the grid/list and 'enter' or use the mouse 3. Nautilus now jumps into the directory 'Pictures', but the Location Bar stays in search-mode. I already tried to bypass this behaviour with toggling 'Ctrl + f' afterwards, but the Location Bar stays in search-mode. If I open the context-menu (key or right click with mouse) I can select "Open in terminal" and it will open a terminal in the previously selected directory, so the current-working-directory is rightly modified. Thank you for your work Peter
Created attachment 325849 [details] screencast, first just hitting enter and in the second time tabbing into the result-grid and hitting enter Hollywood like! Oscar-Achivement unlocked ;)
*** Bug 764916 has been marked as a duplicate of this bug. ***
Created attachment 326025 [details] [review] 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.
Attachment 326025 [details] pushed as 035cd2d - window-slot: fix condition for disconnecting old view
Thanks for your fix. In the very first place your description sound weird (I guess this my fault) to me. Because it bases upon a series of changes from the last days I used jhbuild to use the current master-branch (as you told me): with this settings: repos['git.gnome.org'] = 'https://git.gnome.org/browse/' # behind a company proxy autogenargs = '--disable-selinux' # turn it off, because not on Fedora and this command: $ jhbuild buildone nautilus Anyway still libgd is required, but git clone failed here for some uknown reasion. I downloaded it manually. Finally the compilation succeded, so I have done this: $ killall nautilus # Iassume the working nautilus binary shouldn't run $ /home/peter/jhbuild/install/bin/nautilus The 'Location Bar' is still in the 'Search-Mode' after selecting a directory. I attached a screenshot.
Created attachment 326093 [details] build from master with jhbuild
(In reply to Peter from comment #5) > Thanks for your fix. > > In the very first place your description sound weird (I guess this my fault) > to me. Because it bases upon a series of changes from the last days I used I'm confused here.... what in the commit messages it says it bases the changes in previous changes? > jhbuild to use the current master-branch (as you told me): > > with this settings: > repos['git.gnome.org'] = 'https://git.gnome.org/browse/' # behind a company > proxy > autogenargs = '--disable-selinux' # turn it off, because not on Fedora > > and this command: > $ jhbuild buildone nautilus jhbuild build nautilus to build all the necessary dependencies. > Anyway still libgd is required, but git clone failed here for some uknown > reasion. I downloaded it manually. > > Finally the compilation succeded, so I have done this: > $ killall nautilus # Iassume the working nautilus binary shouldn't run > $ /home/peter/jhbuild/install/bin/nautilus > Looks like you did it correctly (missing dependencies, but if it compiled, it shouldn't affect the result in this specific case) > The 'Location Bar' is still in the 'Search-Mode' after selecting a > directory. I attached a screenshot. hm it works for me... no idea what can be now. Is it always reproducible by you?
I don't mean 'rebase' in sense of git, i mean this fixes: window-slot: fix condition for disconnecting old view window-slot: fix formatting window-slot: remove all dependencies to desktop window-slot: use inheritance for disabling actions window-slot: use inheritance for other locations view window-slot: remove unneeded code special casing desktop window-slot: use action state instead of special casing the search window-slot: allow overriding the creation of views window-slot: make it derivable class
Those changes are unrelated to this issue. This patch should work as it is, and can be backported to 3.20. It might be that there is another issue in the code.
Yes. I share your opinion, but the very first one is your patch for this issue!?
(In reply to Carlos Soriano from comment #4) > Attachment 326025 [details] pushed as 035cd2d - window-slot: fix condition > for disconnecting old view Just a stupid guess. Is this the actual patch for the issue? https://git.gnome.org/browse/nautilus/commit/?id=66c17fa53d0afe1adfcc976d4d5ba52a6c3dc3f3
(In reply to Peter from comment #10) > Yes. I share your opinion, but the very first one is your patch for this > issue!? ah! The patch is attached here in the bug report. So on https://bugzilla.gnome.org/show_bug.cgi?id=764981#c3 I attached the patch, and on https://bugzilla.gnome.org/show_bug.cgi?id=764981#c4 I put the link to the repo commit with "035cd2d" which is the numbers of the commit id.
Hi! I tried it with just this patch on nautilus-3.20.0 https://git.gnome.org/browse/nautilus/commit/?id=66c17fa53d0afe1adfcc976d4d5ba52a6c3dc3f3 Nothing changed. But I noticed the following behaviour (with and without the patch): If I change to the root-directory "/" and just type "dev" and "Enter" the location-bar is updated. This seems to work for every directory one level below "/", for the subdirectories it doesn't update the location-bar. Furthermore I noticed another or releated bug: The plain selection with "Enter" leads to a segfault if the list-view is used for the search. This doesn't happen with the icon-view/grid-view. I can provide you with a strace of it. If you wish. I'm trying to test this in the next days again with JHBuild, maybe something nasty happened or I'm just stupid.
All of those issues were fixed in master and will be backported when it's time. Yeah please try with jhbuild and master (then follow up your insights here :) )
Hello! I was on a trip for the last days and didn't managed therefore to use jhbuild/master again, luckily I saw that 3.20.1 was release including the fix(es). Good news: This is fixed for the list-view and the crash in the list-view is also fixed! Well done! Bad news (You will hate me, I'm so sorry): This is not fixed for the grid-view. To be more exactly this depends on the layout which is used during Type-Ahead/Find. If during Type-Ahead "list" is used, it it fixed! If the grid is used, it is not fixed. I will try to attach a small video. Thank for your patience :)
Hello! I was on a trip for the last days and didn't managed therefore to use jhbuild/master again, luckily I saw that 3.20.1 was release including the fix(es). Good news: This is fixed for the list-view and the crash in the list-view is also fixed! Well done! Bad news (You will hate me, I'm so sorry): This is not fixed for the grid-view. To be more exactly this depends on the layout which is used during Type-Ahead/Find. If during Type-Ahead "list" is used, it it fixed! If the grid is used, it is not fixed. I will try to attach a small video. Thanks for your patience :)
(In reply to Peter from comment #16) > Hello! > I was on a trip for the last days and didn't managed therefore to use > jhbuild/master again, luckily I saw that 3.20.1 was release including the > fix(es). > > Good news: > This is fixed for the list-view and the crash in the list-view is also > fixed! Well done! > > Bad news (You will hate me, I'm so sorry): > This is not fixed for the grid-view. To be more exactly this depends on the > layout which is used during Type-Ahead/Find. If during Type-Ahead "list" is > used, it it fixed! If the grid is used, it is not fixed. > > I will try to attach a small video. > > Thanks for your patience :) aaaagh you are right... :/ No worries about the video, I will try to fix it.
Created attachment 327380 [details] superfluous video, which shows the different behaviour Fine. Your just too fast! I tried so hard to make it nice ;)
This no longer happens with 3.20.3 afaics :)
Created attachment 334523 [details] shows the differences between grid/list-view for browse and search Hi Carlos! I'm really sorry, but it doesn't work. I'm now pretty close to the issue, probably. It works under two different conditions: a) If the selected item is not selected by merely pressing "enter", but using "tab+tab+enter" or "curserdown+enter" b) Using grid-view for browsing and list-view for search. It doesn't matter if this setup was select previously or during searching itself. So it doesn't look like a pure focus/listener related problem? I attached a video showing case b). You will notice, that selecting the same view for browse and search will not work. I just pressed "enter" after typing my search-term, noting more. btw. I'm the guy who missed our second jogging on sunday at GUADEC, I got anyway sick (not caused by alcohol). So you are lucky that you didn't listend on me to start earlier, but sadly I mist the chance to show you that live on my laptop. I have should done this on saturday :-( Thanks
> > btw. > I'm the guy who missed our second jogging on sunday at GUADEC, I got anyway > sick (not caused by alcohol). So you are lucky that you didn't listend on me > to start earlier, but sadly I mist the chance to show you that live on my > laptop. I have should done this on saturday :-( > > Thanks Oh! This is you! You missed a great jogging :D Next GUADEC we will do the same :P Thanks for the video an the report, I will reopen and try to reproduce again. Sadly I cannot reproduce with your steps, but this is an area I want to make sure it works flawlessly. So let's try to fix for 3.20.4.
*** Bug 770207 has been marked as a duplicate of this bug. ***
I'm running into this with 3.22.0, as well.
Is anything happening with this?
Created attachment 348924 [details] [review] window-slot: fix activate on search entry The issue is that when pressing enter in search while the search entry has the focus, right after the callback to activate the selection is called, Nautilus also tries to activate the location corresponding to the base of the search, as the view is still searching. This occurs because in the activated signal the search is set as not visible manually, which will make Nautilus check immediatly if it should go back to the base of the search location, without waiting for the view to update. To fix this, don't set the search as not visible in the activated callback, as when the search-mode-enabled property changes, if necessarry, the cancel signal will be emitted which will set the search as not visible, which will happen only after the view is updated. This is the behavior for activating the selection in other ways, so activation with focus on the entry should behave the same.
Thanks! This interesting, so search-mode was turned off in the callback while it was still working. I will try your fix as soon as possible :)
Review of attachment 348924 [details] [review]: Aha, that sounds sane. Thanks!
Attachment 348924 [details] pushed as c68efe2 - window-slot: fix activate on search entry
Backported all the way to 3.22.
> Attachment 348924 [details] pushed as c68efe2 - window-slot: fix activate on search entry Any idea when there will be a 3.24.x release with this fix, since there wasn't a 3.24.2?
Yes, I will do one tomorrow, sorry for the delay, I completely skipped .2 :/
Wow that's unexpectedly fast, thanks!
Awesome :)