GNOME Bugzilla – Bug 555109
Synthesized crossing events should have proper coordinates
Last modified: 2018-02-10 03:33:35 UTC
I often use type-ahead in the listview to quickly navigate to or near a folder. If I press "return" this correctly opens the folder. If I however double click now, strange things happen. Example: - have a folder TestA and TestB inside your home dir - type "tes", nautilus will select "TestA". - now double click (or just single click) "TestB" - instead of opening "TestB", the first folder in my home dir ("art") is opened
This is still the case in trunk. Also, this is not a GTK bug: doing the same in the file chooser works as expected.
I don't get the same behaviour, when i click on testB it doesn't open anything. In fact I have to tripple click it to get anything to happen, the first click just pops down the typeahead dialog.
Ah, no I can reproduce it. It always happens if you click on the testB expander triangle, but only sometimes when clicking on the rest of the testB row.
I think the problem here is that nautilus never ever sees the first click when the typeahead window is up, instead it goes to the typeahead window, which does: if (event->window == tree_view->priv->bin_window) gtk_tree_view_button_press (GTK_WIDGET (tree_view), event); But thats calls the treeview specific handler directly, overriding the signal handler that nautilus adds. I think it should emit the button_press_event signal instead. Kris: Opinion?
Turns out this is a GtkTreeView bug. To reproduce, use gtk-demo, the "tree store" test. Click on january, then type "f" -> selects february, then click on presidents day. This should select presidents day, but does instead close the january tree. The source of the issue is that when we're hiding the typeahead window we're losing the grab, which somehow synthesizes an enter event on the treeview bin window, but it uses x=0, y=0 for the enter event. The treeview enter event handler handles this as if you had the mouse over 0,0 which means it prelights the expander arrow for the first row. Then when the button event comes we just directly expand this row.
*** Bug 560793 has been marked as a duplicate of this bug. ***
I can also reproduce this without using the typeahead window; if I just press SHIFT or ALT or CTRL, it seems to think i moved my mouse to x=0,y=0 as well as I can see the topmost expander 'light up' (see bug 560793 for more details). In the case of the gtk-demo tree store demo I need to select the list first, but the same problem occurs in nautilus (list view), which tends to mess up selecting multiple files depending on wether or not I move my mouse before I click a the mouse button to complete the selection.
I can confirm the first post by Michael Monrea. The problem also shows in Nautilus 2.26.2.
Shouldn't this be confirmed by popular demand yet? Here is the same bug in the Ubuntu bug tracker: https://bugs.launchpad.net/bugs/295408
Confirming and looking into this. Something seriously got messed up somewhere.
I've put a temporary fix in GtkTreeView's enter-notify handling to ignore the synthesized crossing events. This does not fix everything, but does get rid of the absurd behavior as reported in comment 5 and also in other channels. Issues still are: - Have the mouse pointer over the expander. Expander turns black. Press shift, expander turns white again. This is due to the expander popping up off-screen. (We still want leave-notify to handle the synthesized events, otherwise we still have the absurd behavior). Ideally, the expander only turns back white when the search dialog pops up on-screen (not off-screen). - When you have the mouse over the expander and the search dialog pops down, the expander should probably turn black. For this the enter-notify event needs to be handled. I don't think this is a very big issue for now. Either way, I think that the synthesized crossing events should really have proper coordinates instead of (0, 0). If they cannot have proper coordinates, they should have fake coordinates like (-100, -100). (0, 0) is something in the middle and does not cut it. These events were introduced by the fix of bug 56070.
*** Bug 587074 has been marked as a duplicate of this bug. ***
*** Bug 590187 has been marked as a duplicate of this bug. ***
*** Bug 598128 has been marked as a duplicate of this bug. ***
According to comments on Launchpad in bug <https://launchpad.net/bugs/295408> this issue was fixed from Ubuntu 9.10, which uses Nautilus 2.28.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.