GNOME Bugzilla – Bug 480065
wrong tree collapsed (or expanded) after having scrolled without changing mouse pointer position
Last modified: 2010-01-18 21:14:08 UTC
1. Place the mouse over the arrow of a collapsed tree. 2. Expand it with a click, without moving the mouse. 3. Use the scrollwheel to scroll the treeview without moving the mouse. 4. Click, and see the previously expanded tree collapse, even when it's not under the mouse pointer. I can reproduce this with gconf-editor and evolution at least. I'm not sure, but it may be related with bug #319942.
Created attachment 96150 [details] [review] first attempt to fix it It seems we need to call prelight_or_select () during a scroll event. After reading the code, I (shamelessly) copied/pasted a chunk that seems to take care of this, and the issue seems to be gone with it. (patch against 2.12)
I cannot reproduce this with trunk and gconf-editor. I am sure the mouse is not moved in the process, since the expander arrow stays black after the scroll event (could be considered a bug too). On click, the row the mouse is pointing at gets selected and the expander arrow turns white again, but does not collapse. This bug is not related to 319942.
Created attachment 96958 [details] screencast of the problem Ok, yes, it's not related to the other bug (from the patch I wrote I realized about that). But I can still reproduce it. See this screencast.
I don't think you are using the scroll wheel here; what I basically see happening is: 1. Expand some branches. 2. Scroll down, to the end of the list. 3. Collapse some branch, causing the tree view height to decrease and scroll, the mouse is now no longer above the node that just collapsed. 4. Click expand, the just collapsed row expands again. I tried this multiple times with both testtreeview and gconf-editor on latest trunk and 2-10 and I cannot reproduce it ... As expected the click correctly goes to the row under the mouse pointer, also after the bin_window moved.
Created attachment 96963 [details] actually reproduce the bug as I described in the first place.
I can confirm this one, with gconf-editor on a Ubuntu 7.10, Gnome 2.20.0, gtk+ 2.12.0
I could easily reproduce this on an ubuntu machine of a friend of mine. I wonder what's making the difference here? The X server maybe? I have never been able to reproduce this on my debian machine.
For the record, I use Debian unstable and can reproduce it with both stock debian gtk+ packages and with gtk+/gnome built from trunk with jhbuild. So if any difference, is below the gtk+/gdk/cairo stack. The version of xserver-xorg version I'm running 7.3+2.
On my debian machine I tried both 2-10 and trunk. I think the ubuntu machine was running 2.12. Anyway, to me it feels like some change in GDK or lower is causing this.
I have an updated ubuntu machine these days (7.10, GTK+ 2.12.0, xserver 7.2) and I can still not reproduce this. Is this problem still occurring?
Kris, I just tested this and can reproduce it with GTK+ trunk, everything else remains the same (X.org in Debian unstable).
(xserver-xorg version 1:7.3+15)
Tried again, this time on Ubuntu 8.04, GTK+ trunk and xserver 1:7.3+10ubuntu10.2, and again I do not seem to be able to reproduce this. Could you maybe post the *exact* steps (in text) that you execute to show this problem so I can make sure I am doing exactly the same thing.
I am still seeing this in Ubuntu 10.10. I uploaded a screencast in Ubuntu's launchpad: https://bugs.launchpad.net/bugs/461345 Should I upload it here, instead? It'a 4MB MPEG file.
(In reply to comment #14) > I am still seeing this in Ubuntu 10.10. I uploaded a screencast in Ubuntu's > launchpad: > > https://bugs.launchpad.net/bugs/461345 As far as I can see, that one is even different. Is the scroll wheel used at all to reproduce that?
For some reason I can now reproduce the original issue as reported in this bug. Will be looking into a fix. The patch in comment 1 comes close; but we really want to avoid a call to _get_pointer() here (to avoid server roundtrips).
Fixed; without using a roundtrip. Instead, we now cache the coordinates of the last motion event (a lot of other widgets, including GtkIconView, do this).
Reopened, as I've backed out the patch. It completely breaks epiphany's location bar's entry completion.
It was only committed to master, at the time an unstable branch and this still is an unstable branch. Regressions can always occur on unstable branches, was a direct revert really necessary? Was the revert discussed with a maintainer? As the build was not broken, a direct revert of the patch is not the norm in this case. I have yet to see a proper bug report about the regression that was introduced wrt epiphany's location bar entry.
I reverted it because I considered it a grave regression in functionality and wanted to make sure everybody that does use git master of Gtk doesn't get fed up and use something else. (A lot of people here at the WebkitGtk hackfest considered that.) I thought the best way to achieve a quick response and a discussion going would be to backout revert the patch and reopen this bug, which is why I did that. As for what happens, the action and normal treeviews of the entry completions randomly (un)select the first item when you type into the entry. I have no better way to describe this, but I was thinking you would just use epiphany (or probably any other entry completion) to see it happen.
(In reply to comment #20) > I reverted it because I considered it a grave regression in functionality and > wanted to make sure everybody that does use git master of Gtk doesn't get fed > up and use something else. (A lot of people here at the WebkitGtk hackfest > considered that.) Then why has *nobody* filed a bug or sent e-mail? If people don't tell me that my commit has caused a regression somewhere, then I cannot fix it either. The patch has been in master for almost 3 weeks as we speak. > I thought the best way to achieve a quick response and a discussion going would > be to backout revert the patch and reopen this bug, which is why I did that. It would have been more appropriate to reopen this bug or file a new one explaining the problem and why this patch is the cause of that. Instead of reopening a bug saying "I reverted this because it broke my browser". If everybody would start reverting patches because it regressed something, we would come nowhere further. > As for what happens, the action and normal treeviews of the entry completions > randomly (un)select the first item when you type into the entry. I have no > better way to describe this, but I was thinking you would just use epiphany (or > probably any other entry completion) to see it happen. I will look into trying to reproduce this with the entry completion test app.
(In reply to comment #21) > > As for what happens, the action and normal treeviews of the entry completions > > randomly (un)select the first item when you type into the entry. I have no > > better way to describe this, but I was thinking you would just use epiphany (or > > probably any other entry completion) to see it happen. I have fixed the issues now. Let me know if there are further problems.
Hmm, 2.19.2 as packaged by fedora broke pan here. On startup: Gtk:ERROR:gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: (tree) ....
+ Trace 219746
reverting f59294fd938065a3b306689343bf515b8eb633d7 and f223577a88730a03686935e6d319006595480bd2 "fixed it". I'll reopen. Sorry if the problem is somewhere else.
Ah, looks like some minus signs sneaked in while I was diffing and reapplying. And these change a value that triggered a condition that should not have been triggered ... I have pushed a fix for this to master, so it should be gone now.
could bug #607322 be due to this change?
No, 607322 is affected by the fix for 596473.