GNOME Bugzilla – Bug 673644
Scroll not working in document overview
Last modified: 2012-05-28 14:44:29 UTC
When I'm in the document overview in Gnome-Documents, the mouse scrollwheel (or touchpad scroll) doesn't react. I have to drag the scroobar to scroll. When I open a document. I'm able to scroll with the wheel. I'm using the latest Gnome 3.4, fully upgraded from the Arch Testing repo: https://www.archlinux.org/packages/testing/i686/gnome-documents/
Is anyone going to look into this? This application is just a piece of crap while this is not fixed. It has also been reported on Launchpad https://bugs.launchpad.net/ubuntu/+source/gnome-documents/+bug/973796
Just to be clear, this is not a gnome-documents bug, but a regression in Clutter or GTK+; I haven't been able to track down the actual bug yet.
Strange, I didn't expect it would be a GTK+ or Clutter issue, as I haven't seen other apps with the same problem, and I don't have the problem when I open a document.
-> gtk+ This seems like a bug in the XI2 event handling code; attaching a patch for GDK that fixes this issue.
Created attachment 212460 [details] [review] xi2: fix thinko in variable type
Created attachment 212461 [details] [review] xi2: ignore non-core events for smooth scroll Since the event will be ignored anyway after it's translated (non-core devices are disabled), don't let it run in the smooth scroll code path, as it will burn our caches for the actual event we're interested in.
Review of attachment 212460 [details] [review]: ugh ack
Review of attachment 212461 [details] [review]: The commit message should talk about slave devices, not 'non-core'. Other than that, the reasoning makes sense to me, but it would be good to get garnacho's review.
It sounds like an X bug if it's sending events with deviceid=sourceid=slave and the window doesn't listen to events for that slave device specifically. The patch looks mostly good, the only shortcoming I can see is that if events are enabled for the touchpad slave device it would get no scroll events at all, but that should be a really uncommon thing to do. Finding a good place to reset the delta to serve for 2 events sounds also tricky...
Committed these now, with some extra logging. I'll talk to whot about the questionable extra events we're seeing here.
I see XISelectEvents requests come in for all devices except the XIAllDevices fake device. So the mask is definitely set for that device. That's why you get the event twice. Is this a runaway loop or so on the client that sets all masks?
-> clutter Turns out this might be a clutter bug after all; proposed patch attached. This fixes the bug for me without the workaround in GTK.
Created attachment 212646 [details] [review] device-manager: don't select events for disabled devices I.e. only select events for core devices or devices explicitly enabled by clients.
Review of attachment 212646 [details] [review]: looks good, though you can use device->is_enabled from within clutter-device-manager.c as well. we should also select events when a device becomes enabled.
Created attachment 212708 [details] [review] device-manager: don't select events for disabled devices Use device->is_enabled
Created attachment 212709 [details] [review] device-manager: select/unselect device events as device change When a device is added or changes, select/unselect events from X accordingly.
Review of attachment 212708 [details] [review]: looks good
Review of attachment 212709 [details] [review]: looks good to me
So, should we revert the gdk workaround then ? Any opinion ?
I just noticed that I can't scoll inside Nautilus either. Can someone confirm that, and check if the discussed patches fix that issue too?
(In reply to comment #19) > So, should we revert the gdk workaround then ? > Any opinion ? I pushed both patches to master. If Emmanuele is comfortable backporting the first one to the clutter-1-10 branch and we can have another clutter release with the fix, I think it's better to drop the workaround from GDK, yes.
(In reply to comment #20) > I just noticed that I can't scoll inside Nautilus either. Can someone confirm > that, and check if the discussed patches fix that issue too? No, scrolling in Nautilus should work fine with GTK 3.4; if you have issues there it's better to open a separate bug report against Nautilus.
I can backport when I roll 1.10.2; GNOME 3.4.2 is due May 7th, but I guess I can do a release before that.
1.10.4 was released with these commits.