GNOME Bugzilla – Bug 587074
List View and the "quick search" leading to odd behavior
Last modified: 2009-07-30 18:37:19 UTC
Please describe the problem: When i look at a folder in list view and just start typing letters the selection is scrolled to the coresponding file/folder (that is what i meant with quick search... don't know what the feature is actually called). Now when i exit the little quick search field that poped up with a click somewhere nautilus opens the subfolders of the folder that is currently on top of the list (meaning the part of the list that is visible). This does not happen if i exit the quick search by pressing enter. Then the file/folder in focus is opend. Steps to reproduce: 1. Enter one or more letters to start the "quick search" while looking at a folder in list view 2. Click somewhere (i.e. some file/folder) Actual results: The topmost (visible) folder expands and the subfolders are shown Expected results: Nothing except the quick search enter window vanishing (and maybe the focus changing depending on what i clicked) Does this happen every time? Yes Other information:
Hi, good catch, from the nautilus perspective we can do nothing as this is a GtkTreeView bug, I was able to reproduce it with gnome-device-manager treeview, so I'm changing product accordingly.
Created attachment 137464 [details] [review] Fixes mouse clicking a treeview element with search window opened Hi again!, I took a look at the code and made this patch which is fixing the issue for nautilus and gnome-device-manager, that is, clicking an element of the tree when the search window is opened does not cause the first (topmost) node to be expanded.
Created attachment 137471 [details] [review] Real fix Hi, my prior patch worked fine for single click but when doing a double-click sometimes the bug behaviour appeared again, because the second time the button_press_event was fired then the arrow of the first node was already lit. So I took a deeper look, the real problem comes from the fact that when the interactive_search window is hided a focus_change out is pursued on the search window so the focus gets out of search window, so gdk passes the focus to the treeview window where an enter-notify-event is fired, this event's x and y are zero, and here comes the confusion, because the arrow of the first node of a treeview comes inside the zero x and y range, and so the arrow was lighted and so when doing a new button press the node was expanded. So I've done a new patch that in the enter-notify-event handler checks whether the event comes from the interactive search window hiding (by checking X and Y to be zero and also the GdkCrossingMode of the event) and so in this case we don't light the arrow and so it's not activated by the next mouse button events. Checking the GdkCrossingMode of the event make us distinguish the 0,0 coords that comes from the search window hide from the 0,0 coords that could happen if you enter the treeview with a normal motion-event at that coords. Hope I've explain well so the patch can be reviewed and commited.. thanks!
*** Bug 587617 has been marked as a duplicate of this bug. ***
The (0, 0) coordinates come from the synthesized event generation AFAIK and I think these coordinates should be proper coordinates (those of the mouse pointer) or (-100, -100). For now I've already put in a different fix temporarily. If the behavior of the events appears to be right and won't be fixed, then we need a somewhat better fix here. Yours definitely seems to come close. Marking as duplicate. For future reference: this bug has an idea for a proper fix in case the crossing events won't be changed. *** This bug has been marked as a duplicate of 555109 ***