I believe I may have run into a glib or gtk bug that was ported from gtk2.
I could use some help determining how to debug / gather more information /
work around this issue.

On rare occasions, while in a dialog, all signals and events are not
received for touch or click events -- however, after a keyboard event comes
in, the click events (that appear to have been queued) are now received.

More info:

ubuntu 18.04 server
glib: 2.56.3-0ubuntu0.18.04.1
gtk:  3.22.30-1ubuntu1

I have a piece of code that calls:
and displays a dialog that has text but no button.

After a "background" task completes:
(called by gdk_threads_add_timeout_full( G_PRIORITY_DEFAULT_IDLE, 10,
TimerCallback, 0, NULL );)
the dialog is updated to add an OK button to continue.

Most of the time (perhaps 49/50 times) the OK button receives signals as
expected; however, 1/50 times, no signals/events attached to that button
are received.


1. To the user, the screen appears unresponsive.  Taps (on the touchscreen)
or clicks (with an attached mouse) anywhere on the screen have no effect.

2. I have confirmed (with GDB and with prints in the TimerCallback noted
above) that the g_main_loop_run() is continuing to run freely (no

3. It is possible that this error is more reproducible if the user taps
more than once on the button that triggers the dialog to be created, but
this is not confirmed.

4. For debug purposes, I have attached to the "event" signal, as well as
the "button_press_event" and the "clicked" event of the "OK" button -- no
events of any kind are received when in this state.

5. I confirmed that the touch screen is actively sending data (cat
/dev/input/event5 shows the expected binary output)

6. Once in this state, click events with a mouse are also not received (so
this does not appear to be related to the touch screen, except perhaps for
(3) being easier to reproduce by tapping).

7. If, after tapping "OK" in this state (and nothing happens), the user
then types any key on the attached keyboard, the touch (or mouse click)
events are now received by the button, and the program continues as normal.

Questions / Thoughts:
1. Does anything come to mind which could cause touch / click events to be
queued and not sent to the gtk widget until a keyboard event comes in?
2. Is it possible that, for some reason, an extra click is causing the
focus to not be on the dialog?  But, if so... why would touch events be
queued and then released when a keyboard event comes in?
3. Any suggestions to gather additional debug info?  Is there a good way to
monitor if the touch and click events are being received by GLib?   Where
is the X-input processing queue?  Any suggestions on source code to read?
4. Any suggestions for a workaround?  (Ideally not something like "send
keyboard events periodically" ;-)

Many Thanks,
gtk-list mailing list

Reply via email to