GNOME Bugzilla – Bug 566963
Expand arrows in GtkTreeView stop working sometimes
Last modified: 2017-12-19 18:47:35 UTC
This bug a bit difficult to trigger it doesn't happend every time but ...: Launch anjuta and create the default GTK+ gtk-foo project. Go to the Project pane on the left hand side of the anjuta window and expand the two entries there (gtk_foobar and /) Everything works as expected. 1) Quit Anjuta and launch it again 2) open the project we just created 3) try to expand the gtk_foobar and / entries in the Project pane Maybe this time i will work, quit, repeat 1, 2 and 3 it will reach a point where those entries will not expand any more.
Yes, this actually happens with any tree view inside anjuta which makes this bug quite strage...
It's real very strange, I found it in file-manager some times ago... I'd like to know some news about this bug.:)
I'll try to look into that
- I find it extremely hard to reproduce with current TRUNK - I think it's a timing problem which results in something eating up the single click on the expander, because it disappears if I add some debugging output - Interestingly, pressing return and double click (on file view, as it triggers the options dialog on project view) seems to work quite well Could anyone also getting this bug confirm 3), please?
> - I find it extremely hard to reproduce with current TRUNK Yes, I see this less often now. > - Interestingly, pressing return and double click (on file view, as it > triggers the options dialog on project view) seems to work quite well Well, pressing <Enter> calls "activate" on that row which calls gtk_tree_view_expand() on that row. But that has nothing todo with the expander or a click.
It seems that this test here fails: if (tree_view->priv->button_pressed_node == tree_view->priv->prelight_node on gtktreeview.c, line 3010 on Ubuntu's intrepid packages.
*** Bug 572751 has been marked as a duplicate of this bug. ***
I see this in Evolution, so it might be a gtk+ problem.
If anyone's interested, I have a vmware image with a version of anjuta which can quite eaysily reproduce this bug.
Hmm, reassigning to gtk+, seems it is a problem there.
Having updated the GTK+ version to 2.15.5 this behaviour seems gone, but I don't yet see why
I still see this with latest gtk+
*** Bug 612513 has been marked as a duplicate of this bug. ***
*** Bug 586429 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > - I find it extremely hard to reproduce with current TRUNK > - I think it's a timing problem which results in something eating up the > single click on the expander, because it disappears if I add some debugging > output > - Interestingly, pressing return and double click (on file view, as it > triggers the options dialog on project view) seems to work quite well > > Could anyone also getting this bug confirm 3), please? For double-click or enter the expanding is triggered in software and this always works. The bug only appears when the expanding should be triggered by a click on the arrow.
(In reply to comment #15) > For double-click or enter the expanding is triggered in software and this > always works. The bug only appears when the expanding should be triggered by a > click on the arrow. @jhs: it doesn't work here with the double click. This is a very annoying bug even for symbol-db and the others GtkTreeView.
@Massimo: Where did you try. I depends what the tree-view does on the "activate" signal. Most tree views in anjuta connect the signal to expanding the notes but some (probably the new symbol-model tree) don't.
Let me add my vote too. It happens a lot with me as well .. in file-manager view, in project manager view, in symbol-db view. What seems to happen is that some how the arrow seems to fail noticing that mouse is over it when mouse movement stops. If you move it a little bit, it notices and highlights it, but as soon as you stop the move (still on top of the arrow), it goes to un-highlight state and nothing happens with click. Yes, shift+enter works though.
(In reply to comment #17) > @Massimo: Where did you try. I depends what the tree-view does on the > "activate" signal. Most tree views in anjuta connect the signal to expanding > the notes but some (probably the new symbol-model tree) don't. symbol views double-click is connected to navigating to the class, not expanding.
(In reply to comment #17) > @Massimo: Where did you try. I depends what the tree-view does on the > "activate" signal. Most tree views in anjuta connect the signal to expanding > the notes but some (probably the new symbol-model tree) don't. everytime on the debugger it happens. I must close & reopen anjuta. Really often even in the file-manager and now in symbol-db treeviews.
I can confirm that this happens for me in evolution, too. Trying to investigate...
I was about to report this in Evolution, thinking it was the only affected app where clicks on treeview expander buttons sometimes got "lost", but it also seems to happen "sometimes" with dconf-editor. And when you try to reproduce it, it changes behavior... yay heisenbug! The common thing I have noticed is that when it happens, it will "eat" the clicks until you move the mouse. You only need to move the mouse cursor by a pixel or so for it to start working again (you don't need to "exit" the expander button area).
I found that this is easily reproducible with gtk3-demo's "Tree Store" window. Just opening it and moving the mouse pointer over an expander arrow and then repeatedly clicking on it _without_ moving the mouse between clicks reproduces the bug from the 2nd click onward. What happens is that on gtk_tree_view_button_release() we do a gtk_grab_remove() (the grab was added before in gtk_tree_view_button_press()). Removing this grab causes a leave-notify-event signal to be emitted and the handler (gtk_tree_view_leave_notify()) will remove the expander arrow prelight as well as unselect the tree view node. Fixing this can be accomplished by ignoring these grab/ungrab triggered leave-notify-event signals. But I found another related bug. If one uses the typeahead find functionality which by default pops up an entry at the view's bottom and then immediately clicks on an expander arrow before the search entry pop up times out, then the expander won't work. This happens because, while the search entry is up, no motion notify events are delivered to the tree view whose handler is responsible for setting the expander arrow prelight flag. The fix I thought of for this latter issue actually fixes the first issue too. It consists of calling do_prelight() in gtk_tree_view_button_press() just before we check the expander arrow prelight flag. I think that both fixes may be committed although, strictly, only the latter one is enough to fix both issues. Anyway, I might be missing something here, so a review by who knows this code better is very welcome.
Created attachment 193361 [details] [review] treeview: Ignore leave-notify-event when mode is GDK_CROSSING_GTK_[UN]GRAB Just [un]grabbing shouldn't cause us to [un]prelight the current arrow and node.
Created attachment 193362 [details] [review] treeview: Ensure that prelight flags are updated when handling button press Relying on prelight flags to only be set elsewhere would cause expander arrows not to work in certain conditions.
*** Bug 585892 has been marked as a duplicate of this bug. ***
Hi Rui -- your patches look quite interesting and this bug only shows up in 3.x I think, not in 2.x. Are you sure that the bug you've found is the same as the bugs mentioned in the opening comment of this bug (which is likely to be based on 2.x).? From the first 10 comments on this bug it feels like the expander does not work at all.
This originally happend in 2.x and also happens in 3.x from time to time. I don't know if the patches address the problem but it would be really nice to have that fixed.
I just installed anjuta (GTK+ 2.x based) and clicked around. I cannot really trigger it ... For 3.x. I can confirm the issues with double-clicking. But it still looks like it is a different issue than the issue we saw in GTK+ 2.x, because repeatedly double clicking on the expander works fine in GTK+ 2.x.
(In reply to comment #27) > Hi Rui -- your patches look quite interesting and this bug only shows up in 3.x > I think, not in 2.x. Are you sure that the bug you've found is the same as the > bugs mentioned in the opening comment of this bug (which is likely to be based > on 2.x).? From the first 10 comments on this bug it feels like the expander > does not work at all. Right, I only became aware of this bug in 3.x. To be precise I noticed it first using Nautilus in Fedora 15. I didn't try Anjuta to be honest. But the original reporter does say that the bug is hard to trigger since it doesn't always happen.
To separate the original issue from the GTK+ 3 issue; let's discuss the GTK+ 3 issue in bug 653676.
Comment on attachment 193361 [details] [review] treeview: Ignore leave-notify-event when mode is GDK_CROSSING_GTK_[UN]GRAB I've committed this patch to master and gtk-3-2, in a slightly different form. It introduces the bug at hand, which was caused by leave notify events generated after the button release, which were not there in GTK+ 2.x.
(In reply to comment #25) > Created an attachment (id=193362) [details] [review] > treeview: Ensure that prelight flags are updated when handling button press > > Relying on prelight flags to only be set elsewhere would cause expander arrows > not to work in certain conditions. Rui, could you be more specific about the "certain conditions"? The prelight node should be updated by the motion, leave, enter, etc. notify handlers and not by button press (unless there's a very good reason).
(In reply to comment #33) > (In reply to comment #25) > > Created an attachment (id=193362) [details] [review] [details] [review] > > treeview: Ensure that prelight flags are updated when handling button press > > > > Relying on prelight flags to only be set elsewhere would cause expander arrows > > not to work in certain conditions. > > Rui, could you be more specific about the "certain conditions"? The prelight > node should be updated by the motion, leave, enter, etc. notify handlers and > not by button press (unless there's a very good reason). Yeah, that commit message sucks. I've explained it in comment #23: > But I found another related bug. If one uses the typeahead find functionality > which by default pops up an entry at the view's bottom and then immediately > clicks on an expander arrow before the search entry pop up times out, then the > expander won't work. > > This happens because, while the search entry is up, no motion notify events are > delivered to the tree view whose handler is responsible for setting the > expander arrow prelight flag. > > The fix I thought of for this latter issue actually fixes the first issue too. > It consists of calling do_prelight() in gtk_tree_view_button_press() just > before we check the expander arrow prelight flag. Does that make sense? Anyway, that's a different bug report really. Want me to file one?
(In reply to comment #34) > > But I found another related bug. If one uses the typeahead find functionality > > which by default pops up an entry at the view's bottom and then immediately > > clicks on an expander arrow before the search entry pop up times out, then the > > expander won't work. > > > > This happens because, while the search entry is up, no motion notify events are > > delivered to the tree view whose handler is responsible for setting the > > expander arrow prelight flag. > > > > The fix I thought of for this latter issue actually fixes the first issue too. > > It consists of calling do_prelight() in gtk_tree_view_button_press() just > > before we check the expander arrow prelight flag. > > Does that make sense? Anyway, that's a different bug report really. Want me to > file one? Oh, I completely missed that. It does make sense. It also made me realize a regression introduced by your patch I committed yesterday: 1) Put mouse above expander so it is prelit. 2) Pop up search dialog with C-f. 3) Click elsewhere in the tree view. The expander that was prelit is now wrongly activated. So either we fix enter-notify and leave-notify and we might have to special case things for the search dialog (which has enough special cases throughout the code already). Or we fix button-press; my problem with fixing in button-press is that in theory the coordinates and thus the prelit node should not have changed when we hit button press. I would prefer to keep the responsibility of updating the prelit node to the parts that really affect it.
This bug is present in GTK 2 as well as GTK 3 up to and including 3.18.5. 100% reproducible as follows: If I expand a branch in the tree view side panel by single-clicking the arrow icon with my mouse, the branch expands as expected. But if I wait a few seconds and then single-click again to collapse the branch (without moving the mouse), nothing happens. Note if I move the mouse between clicks, then it works. This bug is now six years old and still appears in GTK 2 and 3.
Doesn't reproduce here anymore, with 3.19. It might have been fixed by f32a54fb705ba787786f108fc93fad2027727eb9
(In reply to Matthias Clasen from comment #37) > Doesn't reproduce here anymore, with 3.19. It might have been fixed by > f32a54fb705ba787786f108fc93fad2027727eb9 Hence closing.