GNOME Bugzilla – Bug 699574
gtk_selection_owner_set() breaks mouse wheel scrolling
Last modified: 2019-02-12 21:18:09 UTC
After upgrading GTK+ to 3.8.1 or 3.9.0, user can not scroll text in Lɜafpad [1] with mouse wheel. (Rebuild Lɜafpad is not helpful.) Mouse wheel is still working in the "scrollbar area". That is, when user want to scroll with mouse wheel, he/she have to move cursor to the right side, put the cursor on top of scrollbar, and use the mouse wheel. Revert GTK+ commit cc7b3985b3e313a02e9eb06facb0cec4e471df60 fixes the problem. [1] http://www.calno.com/l3afpad
Seeing this in current Fedora 19, with Evolution.
*** Bug 699561 has been marked as a duplicate of this bug. ***
I also have this problem with GTK 3.8.2 on Ubuntu with a Cairo-Dock session (with Compiz). The commit cc7b3985b3e313a02e9eb06facb0cec4e471df60 should fix the bug #690275 but as I said on this bug report [1] it also introduces this bug. Note: this bug is also tracked on Launchpad: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1184159 This change was also added on Ubuntu Raring 13.04 but then it was removed due to this bug. It was tracked on Launchpad too: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171156 (you can find a few screencasts/tests). E.g.: - Before: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171156/+attachment/3650661/+files/gtk_scroll_1171156_without_patch.ogv - After: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171156/+attachment/3650662/+files/gtk_scroll_1171156_with_patch.ogv - It seems this bug doesn't affect Gnome-Shell session: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171156/comments/10 @Wen-Yen & Adam: which WM are you using? [1] https://bugzilla.gnome.org/show_bug.cgi?id=690275#c8
I think this bug is WM independent. Anyway I use evilwm.
Created attachment 245467 [details] [review] patch, testing welcome After quite some testing I've been only able to trigger this with evolution, by: 1) replying to someone 2) selecting some in the mail view text with the usb mouse 3) trying to scroll with the wheel after that After that XI scroll events come together with a burst of crossing events to/from the inferior WebKitWebView (even though the pointer doesn't actually cross any window boundaries) that clobber the scroll valuators. This patch ignores events towards/from inferiors for resetting so scrolling works again on evolution. Testing is welcome on l3afpad or any other places it can be seen though, I'm not that sure it'd help there as that's pretty much a stock textview, and I don't see how native child windows could be involved there...
(In reply to comment #5) > 2) selecting some in the mail view text with the usb mouse "selecting some text in the mail view..."
Hello Carlos and thank you for this patch! I just tested it but I still have this bug with Gedit and Nautilus. It's maybe a bit better now but it's still not so smooth as before. Screencast of the bug with the patch from comment #5: http://videobin.org/+6mq/7us.html As you can see on this screencast, scrolling up is still fine and scrolling down is still a bit buggy but maybe only at the beginning now (we can see some lags when starting to scroll down) and after is not so fast as before.
Downstream bug report about this from evolution 3.8.3: https://bugzilla.redhat.com/show_bug.cgi?id=983149 The user claims it gets broken since he selected a text, which I can confirm. Maybe the evolution bug #699561 can be workarounded in some way. I noticed it doesn't matter which way I select the text, it can be both by mouse or by keyboard.
The issues on Ubuntu/unity can be traced to the 'xi2: Reset scroll valuators on synthesized crossing events' commit & a compiz plugin, 'viewport switcher' They occur when bindings are set in "Desktop-based Viewport Switching" , typically, - next = button 5, prev = button 4 In addition to the poor scrolling in select windows, all scrolling with a mouse scrollwheel can be lost when using a usb mouse on a laptop in a significant number of windows https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1200829 I guess it may be compiz's issue now, for whatever reason that commit & that plugin's two 'scroll on desktop' binding's don't jive.
Created attachment 249171 [details] [review] gtkhtml workaround for gtkhtml; I identified the issue down to call of gtk_selection_owner_set(). If this one is not called, then the scrolling works as expected, thus that's something about this function, breaking the event delivery. I also run the gtkhtml-editor-test with GDK_DEBUG=events and the result is that there are not received all scroll events, like before the call. I'm committing this workaround to gtkhtml, because I didn't notice any negative side effects (and the doc says it's usually not necessary to call this function at all, when using GtkClipboard API). I keep the bug opened for further investigation on the gtk+ side.
Created commit 6d47743 in gtkhtml master (4.7.1+) Created commit 5d85f53 in gtkhtml gnome-3-6 (4.6.6+)
*** Bug 703820 has been marked as a duplicate of this bug. ***
Created attachment 250767 [details] .xsession-errors .xsession-errors from session with GTK mouse scrolling bug.
(In reply to comment #13) > Created an attachment (id=250767) [details] > .xsession-errors > > .xsession-errors from session with GTK mouse scrolling bug. Bug is still present with gtkhtml3-4.6.6-1.fc19.i686 and evolution-3.8.4-2.fc19.i686, even with no text having been selected.
OK, I tried to reproduce it under KDE, and I see it there too. Running: $ GDK_DEBUG=events gtkhtml-editor-test shows that the scroll events are received, thus it's something in the editor, or some place where the events are masked out.
After some testing and playing with gtk3, I see the GDK_SCROLL_SMOOTH (type of) event is received by the GtkScrolledWindow, but the event contains 0 deltas for both x and y, thus the window ignores the signal and passes it to its parent. I have a scratch builds of gtk3 with debug prints to console which shows that at http://koji.fedoraproject.org/koji/taskinfo?taskID=5783707 (for Fedora 19). From that, I believe the issue is with KDE and the bug should be reported there. I can reproduce the same in gtk3-demo, on the main screen of the demo application.
(In reply to comment #16) > After some testing and playing with gtk3, I see the GDK_SCROLL_SMOOTH (type of) > event is received by the GtkScrolledWindow, but the event contains 0 deltas for > both x and y, thus the window ignores the signal and passes it to its parent. I > have a scratch builds of gtk3 with debug prints to console which shows that at > http://koji.fedoraproject.org/koji/taskinfo?taskID=5783707 (for Fedora 19). > > From that, I believe the issue is with KDE and the bug should be reported > there. I can reproduce the same in gtk3-demo, on the main screen of the demo > application. Comments added to https://bugs.kde.org/show_bug.cgi?id=321284
Created attachment 256994 [details] [review] Account for GDK_DEVICE_TYPE_FLOATING too This has been tested by a couple of people and fixes this issue as well as another on Ubuntu. This is my first patch, so hopefully I got it right, but if not, let me know and I'll fix it. Thanks!
Xfce/Xfwm is also affected since it binds workspace switching to the mouse wheel by default.
Would anyone with more Gtk+ experience like to share some insight on this matter? It very annoying having this behaviour broken, as it is one of the most likeable features of a Linux desktop since forever. Chris, who proposed a working patch above, was told by another Ubuntu dev that this patch reverts another fix, namely, for #690275. (I didn't notice this while testing his patch but I suppose they checked it.) So in the end it's something broken either way and no one knows how to fix this.
Carlos, do we still need your patch ? There has been quite a bit of activity here - could you try to look at what change (if any) we need here ?
Yes, I think the patch is still worth applying, it only ensures the behavior that was meant to have since the beginning, as we just care of toplevels when resetting axes. I confirm it still applies cleanly.
lets get it in, then
what about the other patches here ?
*** Bug 708570 has been marked as a duplicate of this bug. ***
Review of attachment 256994 [details] [review]: As discussed on IRC back then, doing (foo != a || foo != b) is kind of a logical puzzle, as any of both statements is going to be true whatever the value of foo is, so this is intricately returning to the previous behavior before the patch
After some further investigation, I pushed https://git.gnome.org/browse/gtk+/commit/?id=4168c3cab9cb17bb4c75bd2f60c13c149afbf29c , which is the patch in comment 5 with some minor modifications and a more accurate commit log. I hence closing this bug, I also pushed https://git.gnome.org/browse/gtk+/commit/?id=962415aeb7e9e47f61c006a5d817a15d181c5055 , so if anyone steps on this bug again (or thinks so), the output of an affected application with GDK_DEBUG=events will be really handy
Hello and thank you for your help! According to Doug McMahon on Launchpad[1], this commit doesn't fix this bug when using it with the old 3.8.6 version. [1] https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1184159/comments/16
Hey Matthieu, as suggested it'd be great if he'd run any affected process with GDK_DEBUG=events after applying 962415aeb too, attaching here the output here should provide a better insight
Created attachment 260095 [details] Output of `env GDK_DEBUG=events evince FILE.pdf` when scrolling is jerky Hey Carlos, Here is what I did to reproduce this bug (with GTK 3.8.6 on a Cairo-Dock session: Cairo-Dock and Compiz launched with gnome-session): * Open gnome-terminal * Launch Evince (I tried with Evince 3.10.2 and with this command: `env GDK_DEBUG=events evince file.pdf`) * Click on terminal's window * Now try to scroll in the Evince window (when this window doesn't have the focus) => scrolling is slow and jerky Gdk-debug.txt file contains messages that I had when doing the last step (when scrolling is slow and jerky). I hope it will help you to find what's wrong :-)
Created attachment 260135 [details] Output of scrolling unfocused gedit window Unfortunately, I don't think this bug is fixed by the patch. This is the output of trying to scroll an unfocused gedit window using the wheel of a USB mouse. I believe this may be a better reproduction case as it doesn't seem to be dependent on the WM or DE. Make sure to try this using a USB wheel mouse. Here are the steps I use to reproduce: 1. Open a Gtk app such as gedit. 2. Make sure there is enough text in the window to get scrolling. 3. Unfocus the Gtk window. 4. Move mouse pointer inside the Gtk window and try scrolling with the wheel. No scrolling occurs. It will scroll when reverting commit cc7b3985b3e313a02e9eb06facb0cec4e471df60. Hope this helps and let me know if I can do any more debugging and/or testing. Thanks!
I confirm Chris' bug but note that I'm able to reproduce it with my touchpad.
Ok, it looks like this patch may not be such an improvement on compiz, and maybe other reparenting window managers. As the passive grabs are set on the application's toplevel parent window created by compiz, the application toplevel is "left" too when the scroll button grabbing happens, with a XINotifyVirtual detail as it's an intermediate window in the chain. This way to do passive grabs indeed defeats scroll axis maintenance. as it looks very much to GTK like the pointer moved to a window outside the application (which it logically did). As for a plausible fix. I think it's be pretty much safe to assume that application-undetected scrolling won't happen while on a passive grab, so GTK+ could be checking for xev->detail != XINotifyPassiveUngrab in that condition. However, Xorg mistakenly sends XINotifyGrab/Ungrab for passive grabs too, which makes it impossible to discern active from passive grabs, this is an Xorg bug that needs fixing.
Hi Carlos, What are our next steps here? Does someone need to enter a bug for Xorg? Who will fix this for Xorg? This regressed behavior seems to be affecting quite a few users, so getting a proper fix would be great. Let me know if I can do anything to help. Thanks!
Hey Chris, I've just pushed fee754e0d22e, which is the last nail GTK+ can put here. I've also reported https://bugs.freedesktop.org/show_bug.cgi?id=71762 so the Xorg bug doesn't get lost, I'll get to investigate the xserver bug and report my findings there.
*** Bug 710619 has been marked as a duplicate of this bug. ***
*** Bug 712174 has been marked as a duplicate of this bug. ***
I am the reporter of bug 712174 For test I rebuild the fedora package gtk3-3.8.6-1.fc19 to gtk3-3.8.6-3.fc19 with the patch in comment 5. For me that work, scrolling in gedit window with kde work fine. If that help you.
The bug is also present on fedora20 beta and gtk3 3.10. I rebuild with the patch and scroll work fine in gedit and other gtk app.
Thanks Carlos! I'll keep an eye on these bugs for additional testing/debugging.
*** Bug 722157 has been marked as a duplicate of this bug. ***
I am affected by this bug on debian sid running under the latest stumpwm window manager compiled from git. using the latest? gtk applications compiled sunday using jhbuild evince nautilus eog gedit namely, my wheelmouse does not scroll the text on pdf documents at all. We noticed it with evince, because we mostly use ls/emacs so the other applications were only noticed later. here is output on my machine when I run xev under stumpwm and scroll my mouse wheel: VisibilityNotify event, serial 36, synthetic NO, window 0x1600001, state VisibilityUnobscured Expose event, serial 36, synthetic NO, window 0x1600001, (411,531), width 137, height 17, count 0 EnterNotify event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667144567, (238,298), root:(3119,299), mode NotifyUngrab, detail NotifyAncestor, same_screen YES, focus YES, state 4096 KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonPress event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667144566, (238,298), root:(3119,299), state 0x0, button 5, same_screen YES ButtonRelease event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667144566, (238,298), root:(3119,299), state 0x1000, button 5, same_screen YES LeaveNotify event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667145543, (238,298), root:(3119,299), mode NotifyGrab, detail NotifyAncestor, same_screen YES, focus YES, state 4096 EnterNotify event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667147967, (238,298), root:(3119,299), mode NotifyUngrab, detail NotifyAncestor, same_screen YES, focus YES, state 4096 KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 4294967204 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonPress event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667147966, (238,298), root:(3119,299), state 0x0, button 5, same_screen YES ButtonRelease event, serial 36, synthetic NO, window 0x1600001, root 0x1a4, subw 0x0, time 667147966, (238,298), root:(3119,299), state 0x1000, button 5, same_screen YES One commenter on stumpwm mailing list mentions Also, evince seems to be using XInput heavily (it is the only application on my computer, apart from Xournal, that distinguishes between fingertouch of a touchscreen (which results in scrolling) and touch with pen (which does nothing)) Is there a git branch I can pull from to try to recompile using jhbuild and check the fix?
This bug has reappeared on my system, running KDE and trying to scroll in inactive windows such as Evolution, Evince, and gEdit. Operating System: Arch Linux KDE Plasma Version: 5.14.5 KWin Version: 5.14.5 Qt Version: 5.12.1 KDE Frameworks Version: 5.54.0 Kernel Version: 4.20.7-arch1-1-ARCH OS Type: 64-bit Processors: 8 × Intel Core i7-8650U CPU @ 1.90GHz Memory: 15.4 GiB of RAM