GNOME Bugzilla – Bug 696640
GtkButton: Don't suppress unhandled mouse events
Last modified: 2013-05-18 12:50:37 UTC
This would fix the "back button" event on some mice not bubbling up to the top-level window when a button is under the cursor.
Created attachment 239865 [details] [review] GtkButton: Don't suppress unhandled mouse events Mouse events that we do not handle should bubble up to the parent widget, so they can be handled there, instead of disappearing inside the button.
Review of attachment 239865 [details] [review]: it would probably be a good time to use GDK_EVENT_PROPAGATE and GDK_EVENT_STOP instead of FALSE and TRUE (respectively) as the return value. aside from that, I think it's a good thing to do, and we should audit the various widgets in gtk to ensure that they are not blocking event propagation unless they are actually handling events.
I went through the widgets handling ->touch, ->button_press_event and ->button_release_event, and found that: - GtkButton was a broken one (as per above) - GtkMenuShell's code always eats events, but I guess that's because a grab would be in place anyway(?) - GtkSwitch doesn't check for the primary button and always eats events
Created attachment 244386 [details] [review] GtkButton: Don't suppress unhandled mouse events Mouse events that we do not handle should bubble up to the parent widget, so they can be handled there, instead of disappearing inside the button. Also use GDK_EVENT_{STOP,PROPAGATE} to make return values clearer.
Created attachment 244399 [details] [review] GtkSwitch: Don't handle events from extra mouse buttons Also use GDK_EVENT_{STOP,PROPAGATE} to make return values clearer.
Pushed to master and gtk-3-8 after review by Benjamin Attachment 244386 [details] pushed as 7d54fc1 - GtkButton: Don't suppress unhandled mouse events Attachment 244399 [details] pushed as 41b07bd - GtkSwitch: Don't handle events from extra mouse buttons