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 786683 - unresponsive with "_gtk_widget_captured_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed"
unresponsive with "_gtk_widget_captured_event: assertion 'WIDGET_REALIZED_FOR...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-08-23 14:22 UTC by Hin-Tak Leung
Modified: 2018-05-02 18:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hin-Tak Leung 2017-08-23 14:22:48 UTC
See downstream bug report with analysis and backtrace:

https://bugzilla.redhat.com/show_bug.cgi?id=1435911

Once in a while, cut and paste into a terminal via right-click-paste results in the whole screen freezing and unresponsive. (mouse cursor still moves), until one does ctrl-alt-fN and kill the gnome-terminal-server in a vt.

The problem is traced down to gdk doing a gdk_seat_grab on null.
Details below copied from
https://bugzilla.redhat.com/show_bug.cgi?id=1435911#c9 and
https://bugzilla.redhat.com/show_bug.cgi?id=1435911#c10


===
...
  • #2 gdk_seat_grab
    at gdkseat.c line 302
  • #3 popup_grab_on_window
    at gtkmenu.c line 1771
  • #4 gtk_menu_popup_internal
    at gtkmenu.c line 1992

popup_grab_on_window() is doing a blind gdk_seat_grab() with window=0 without checking;

and in gtk_menu_popup_internal(), near line 1992:

===
  if (xgrab_shell == widget)
    popup_grab_on_window (gtk_widget_get_window (widget), pointer); /* Should always succeed */

  gtk_grab_add (GTK_WIDGET (menu));
====

I think that gtk_grab_add() is what causes the pile of assertions later.

shouldn't it do this instead?
===
if (gtk_widget_get_realized (memu))
    gtk_grab_add (GTK_WIDGET (menu));
====
Comment 1 Daniel Boles 2017-08-23 19:52:41 UTC
Have you confirmed that your suggested patch (minus the typo) seems to resolve this?

It's unclear to me how that would be the only problem caused by the menu being unrealised at that point, considering how much else is done with the menu earlier in this function.
Comment 2 Hin-Tak Leung 2017-08-23 20:30:37 UTC
No, firstly, the bug is intermittent - I only get it once every couple of weeks or something, but when it happens, it is super-annoying; secondly, I am hoping that somebody more familiar with that part of the code can come up with an "obviously correct" fix, instead of trying something that may or may not work.
Comment 3 Stijn van Drongelen 2017-10-20 12:17:21 UTC
I encounter the same intermittent bug. Sometimes it's once a day, sometimes the bug occurs weeks apart. My problem isn't with gnome-terminal, because I use MATE, but with Pluma (MATE's gedit). When I try to save a file and provide the filename, the "Save as..." dialog becomes unresponsive before or after typing the first character. The editor becomes unresponsive as well, which is also abnormal.
Comment 4 Stijn van Drongelen 2017-10-20 12:22:20 UTC
Please note that this bug seems to have existed at least since 2009-11-25: https://bugs.launchpad.net/ubuntu/+source/pavucontrol/+bug/487908

wxWidgets seems to have implemented a workaround for this bug, which might be useful information if you want to reproduce it: https://trac.wxwidgets.org/ticket/15221
Comment 5 GNOME Infrastructure Team 2018-05-02 18:54:33 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/885.