GNOME Bugzilla – Bug 726878
Top level widget receives both GDK_SCROLL_UP/DOWN and GDK_SCROLL_SMOOTH at same timing
Last modified: 2018-04-15 00:32:34 UTC
Created attachment 272630 [details] sample XI2 can sends smooth wheel scroll. So GDK filter out emulated (old) scroll event by the following changeset. commit 7d8962da7c17454007c4bb4927baf91cdb4d6997 Author: Carlos Garnacho <carlosg@gnome.org> Date: Tue Jan 24 00:09:40 2012 +0100 gdk: Filter out either smooth or non-smooth event depending on the evmask If a device provides both smooth and non-smooth events, the latter will be flagged with _gdk_event_set_pointer_emulated() so the client side window receives one or the other. If a device is only able to deliver non-smooth events, those will be sent, so both direction/deltas may need to be handled. Then, if mouse (Xi2) supprts smooth scroll, non-top level widget such as text view receives GDK_SMOOTH_SCROLL only, instead of GDK_SCROLL_UP/DOWN. But if top level widget, it receives both. So GDK should filter out emulated scroll event even if top level widget.
I think it's related - http://permalink.gmane.org/gmane.comp.gnome.desktop/46513
https://git.gnome.org/browse/gtk+/commit/?id=7d8962da7c17454007c4bb4927baf91cdb4d6997 is returning FALSE for unlinking the native window event from the event queue. That means that the "filter[ed] out" events are sent to the native window instead of the client side window. I suspect the intention was to filter them out altogether, which would be achieved by returning TRUE.
Seeing as Martin is working on the firefox gtk3 port and I had the same problem in the LibreOffice gtk3 port I guess its worth mentioning here that if I connect to the toplevel window I got both scroll events, but if I put an eventbox inside the toplevel and connected to that gtk_event_box events then I just get one set of events which is our solution to this (as well as the solution to a whole other bunch of problems in general with connecting to events of the toplevel window under wayland).
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new