GNOME Bugzilla – Bug 105642
dialog destroyed on repeated Esc keypress
Last modified: 2011-02-04 16:11:59 UTC
When I press escape to close a dialog window then sometimes the dialog is destroyed. I think it is because there are several "close" signals generated and the first close stops the gtk_dialog_run() main loop and removes the event handler that prevents the dialog from being destroyed. Then the next "close" in the queue comes and the dialog is destroyed. Maybe the rest of the close (or escape) events should be filtered out? I don't know all about these things so I won't try to fix it. I'm not even 100% sure that it really is a bug, maybe it is by design. In practice the programs should handle the case where the window is destroyed anyway, but that is unrelated. Please try the test case (Soon to be attached). Keep the escape key down to trigger the bug. ps. I have gtk 2.0.6 but I've looked at the cvs code and it looks like it's still there. But someone should reproduce it in gtk 2.2
Created attachment 14217 [details] Test case
This is definitely not legitimate code -- having a key press handler during gtk_dialog_run() that calls gtk_dialog_run() again. But perhaps we can be a little more robust against it.
The "key-press-event" is connected to the top level window and runs the dialog when invoked. It should not be active while the dialog runs. Or maybe I missunderstand something here?
Ah, yes, even worse, you are calling gtk_dialog_run() while the dialog is already running :-) [ Again, we should be more robust against that ]
Created attachment 16710 [details] Modified version of test case to work with 2.2
Looking at it some more, it has nothing to do with anything your code is doing, except for keeping it around multiple times. I think the problem is a very generic one .... queued up key presses can be sent to a window even after it has been hidden. And the default handler for Esc on a dialog not within gtk_dialog_run() is to destroy the window. Putting if (!GTK_WIDGET_VISIBLE (window)) return; at the top of gtk_window_key_press() fixes the symptom here, but I suspect the real fix should go into GDK. I don't thing GTK+ should ever be delivering key or mouse events to a window that is not viewable (window and all parents mapped), though asynchronicity and window manager overrides make the determination of what is viewable or not a rather fuzzy concept.
See for patch and some discussion: http://mail.gnome.org/archives/gtk-devel-list/2003-June/msg00024.html
The following should fix the immediate problem. Fri Jun 6 11:07:33 2003 Owen Taylor <otaylor@redhat.com> * gtk/gtkwidget.c (event_window_still_viewable): Before delivering an event to a widget, check that (if relevant), the event's window is still viewable. (#105642, Dennis Björklund) * gdk/gdkwindow.c (_gdk_window_destroy_hierarchy): NULL out private->parent, since after destruction it might not be valid any more. * gdk/gdkwindow.c (gdk_window_is_viewable): Fix some accesses before g_return_val_if_fail(). Treat DESTROYED windows as unmapped. I filed a bug about related issues with missing notifications that cause problems for paired-event handling as bug 114744.