After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613308 - Propagate unhandled scroll events from GtkPlug to GtkSocket even when in different processes
Propagate unhandled scroll events from GtkPlug to GtkSocket even when in diff...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2010-03-19 09:10 UTC by Karl Tomlinson
Modified: 2018-02-10 03:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
X11 implementation (5.43 KB, patch)
2010-03-19 09:24 UTC, Karl Tomlinson
none Details | Review
X11 implementation (5.48 KB, patch)
2010-07-29 00:01 UTC, Karl Tomlinson
needs-work Details | Review

Description Karl Tomlinson 2010-03-19 09:10:13 UTC
(Mouse wheel) Scroll events are only propagated from GtkPlug to GtkSocket when
they are in the same X client (same process).

Prior to GDK client-side windows an embedder would receive scroll events when
the pointer was over an embedded client from another process iff ButtonPress
events had not been selected in the embedded client.  It was possibly a bit
counterintuitive that when the client selected GDK_BUTTON_PRESS_MASK events it
also interrupted GDK_SCROLL_MASK events from reaching the embedder.

Since client-side windows, toplevel windows always intercept ButtonPress
events, and so their embedders never get scroll events when the embedded
client is (or scrolls to) under the pointer.

The XEmbed Protocol Specification doesn't currently specify any behavior for
scroll events, but propagating them from plug to embedder is useful.
Comment 1 Karl Tomlinson 2010-03-19 09:20:23 UTC
Perhaps button events or other mouse events could be propagated too, but
scroll events seem the most wanted.  For probably similar reasons, GDK_SCROLL
is already treated specially for insensitive widgets in gtk_propagate_event.

Button events can actually be tricky because the embedder can't steal a
pointer grab from its embedded client (unless they are the same X client).
I'm not expecting this to be an issue with scroll button events because with
scrolling events the ButtonRelease seems to have the same timestamp and the
ButtonPress, implying that the duration of the automatic pointer grab is zero.
Comment 2 Karl Tomlinson 2010-03-19 09:24:44 UTC
Created attachment 156542 [details] [review]
X11 implementation

I've used XSendEvent with an event_mask and propagation to most closely
simulate what would happen if the embedded client hadn't selected button
events, which is also similar to the behavior with the GtkPlug and GtkSocket
in the same X client.  (This is different from the empty event mask used to send
key events from the embedder to the plug, but sending messages to descendant
windows is different because propagation doesn't make sense in that case.)
Using propagation for scroll events also means that support only needs to be
added to the plug implementation.
Comment 3 Karl Tomlinson 2010-07-29 00:01:23 UTC
Created attachment 166748 [details] [review]
X11 implementation

Added a socket_window null-check.
Comment 4 André Klapper 2012-05-06 21:41:02 UTC
Comment on attachment 166748 [details] [review]
X11 implementation

Patch uses API deprecated in 2.2x and removed in 3.x: GTK_WIDGET_TOPLEVEL
=> marking as "needs-work"
Comment 5 Matthias Clasen 2018-02-10 03:41:08 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.