GNOME Bugzilla – Bug 734357
GtkListBox doesn't get events delivered for GtkStack children
Last modified: 2014-08-12 12:36:38 UTC
Created attachment 282696 [details] Test app demonstrating the issue We have a page in gnome-software that has GtkStack children packed in a GtkListBox. This used to work fine in past but has regressed at some point. It seems that GtkStack somehow eats up mouse click events and they never get delivered to the listbox. This manifests in unclickable rows that don't do anything. I did a minimal testcase which I'm attaching here. Editing the file and changing '#if 1' to '#if 0' switches between GtkBox and GtkSTack children and the latter breaks the test.
Carlos, this looks like gesture porting fallback maybe ?
It didn't strictly look like that in the end, I'm unsure though how it used to work before, I don't see many changes that could have affected GtkStack's bin window evmask, which I think is the culprit. I however found some gesture fallout while fixing this, attaching here the patch as well.
Created attachment 283111 [details] [review] widget: Include event controllers' event mask on gtk_widget_get_events() gtk_widget_get_events() must indeed tell about events enabled purely through a GtkEventController, those events will most surely trigger event handlers.
Created attachment 283112 [details] [review] stack: Ensure the bin window has an evmask suitable to windowless children If a child has set_has_window == FALSE, it purely relies on the events set on the parent window, for which the bin window used to just ensure the exposure mask, eating all input events.
Review of attachment 283111 [details] [review]: should probably adjust the documentation to point out that this is not fully symmetric with set_events anymore, but includes events from gestures
Review of attachment 283112 [details] [review]: ok
(In reply to comment #5) > Review of attachment 283111 [details] [review]: > > should probably adjust the documentation to point out that this is not fully > symmetric with set_events anymore, but includes events from gestures Good point, the relation between those should be documented indeed. I at first thought that controllers' evmask still strictly fitted into the "events that the widget will receive" description. I'm pushing a patch that adds also explains this further in docs.
Attachment 283111 [details] pushed as 6250777 - widget: Include event controllers' event mask on gtk_widget_get_events() Attachment 283112 [details] pushed as 8ff4757 - stack: Ensure the bin window has an evmask suitable to windowless children