Since gtk+ 3.0, we use XInput2 events for all input, and since 3.14, we use the XInput 2.1 smooth scroll events. It looks to me like you're grabbing/replaying on events gtk+ doesn't listen for anymore.

It could be confirmed if the gtk3 apps behave properly in this regard if the GDK_CORE_DEVICE_EVENTS envvar is present.

export GDK_CORE_DEVICE_EVENTS=1 causes the expected behavior, but I don't follow "you're grabbing/replaying on events gtk+ doesn't listen for"

Even replaying _any_ button uncoditionally has no impact here.

I suspect hat the problem is that the replay causes a enter/leave frame across the event and that breaks the generation of "smooth" scroll events?

(In reply to thomas.luebking from comment #2)
> export GDK_CORE_DEVICE_EVENTS=1 causes the expected behavior, but I don't
> follow "you're grabbing/replaying on events gtk+ doesn't listen for"
> 
> Even replaying _any_ button uncoditionally has no impact here.
> 
> I suspect hat the problem is that the replay causes a enter/leave frame
> across the event and that breaks the generation of "smooth" scroll events?

Hmm, you've just reminded me of https://bugzilla.gnome.org/show_bug.cgi?id=699574.

You're in short right, let me explain what happens: Smooth scroll events come as XI_Motion with vscroll/scroll axes. These are unfortunately cumulative though, so you don't get guarantees after you enter a window that the previous stored values are valid in order to calculate dx/dy out of these. In order to fix this, we raise a flag on enter so the first scroll event after is used as the base for the next scroll events.

This is not a problem unless on wheel mice, because you get one such XI_Motion event per button event, so what happens here is:

- scroll "button press" happens
- passive grab kicks in
- pointer "leaves" the client window
- event is replayed
- pointer "enters" the window, the "reset scroll counters" flag is raised
- button event is replayed, ignored by gtk though
- XI_Motion event arrives too, but is silently ignored as we don't have a "base" to calculate dx/dy from.

The gist of the problem I'd say is knowing that such leave event can be safely ignored, although the crossing event detail isn't too helpful (equal to active grabs'). I filed https://bugs.freedesktop.org/show_bug.cgi?id=71762 some time ago, but the fix wasn't in the end suitable, and it will be hard to come up with something that is both compliant to the spec and backwards compatible.

As for possible solutions that don't go through changing Xserver, I'm not sure, every time I thought about a fix in the gtk+ side I came up with nothing, best I can recomment is that WMs stop grabbing buttons so proactively, at least without modifiers specified.

a) Heuristic approach:
You'll have a leave/enter/motion cycle at "ludicrous speed™", so you could simply clock_gettime() on leave and enter, if that's < 2 ms or so, leave original time and flag untouched, clock_gettime() on the motion event again and if it's still below 2 ms (and maybe the distance from the last event "reasonable"?) take it as "not caused by any human interaction"

b) event selection:
Alternatively, you might record the wheelbutton event and if the motion needs to be skipped, post the wheel button (if present) instead.



WMs hold a passive grab to pass around focus, raise windows etc. - with a lot of special casing code (and restriction the options for wheels) one could probably provide a(n alternatively "partial") workaround, but that's rather ugly (esp. on the "partial" thing, one of the main problem is the inconsistent wheeling...) - and will just fail for you with the next WM to run into this.

Bug #750994 is another variation of the same root issue, I attached a patch there that will also fix this bug.