Description of problem: If I have an error up (such as domain creation failed), other existing virtual machine consoles do not acccept keyboard or mouse input. Version-Release number of selected component (if applicable): virt-manager-0.2.5-1.el5
change QA contact
Out of curiosity I started looking into this. It seems similar to behavior described in http://bugzilla.gnome.org/show_bug.cgi?id=529740 Though the actual bug seems to also be upstream: http://bugzilla.gnome.org/show_bug.cgi?id=536664 Curiously though, looking through the virt-manager-0.5.3 code, all instantiation of vmmErrorDialog appear to be with flags=0 (i.e. not setting GTK_DIALOG_MODAL). Since clearly the dialog is modal, perhaps there's another bug in GTK or pyGTK wherein GtkMessageDialog's are always modal?
Dug into pygtk docs and found the cause: http://www.pygtk.org/docs/pygtk/class-gtkdialog.html#method-gtkdialog--run "...During the run() method, the default behavior of "delete_event" is disabled; if the dialog receives a "delete_event", it will not be destroyed as windows usually are, and the run() method will return gtk.RESPONSE_DELETE_EVENT. Also, during the run() method the dialog will be modal.""" So, it doesn't matter if flags includes GTK_DIALOG_MODAL or not, MessageDialog will always be modal as long as Dialog is.
This mainly boils down to the use of 'run' rather than 'show' with a 'hide' callback. I just fixed this upstream, now all error dialogs should be nonmodal: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/274eb4f5fe61 I'm reassigning to rawhide. If a customer ever files a report for this issue, we can re-examine backporting the change, though it will be more difficult since there has been lots of error reporting consolidation upstream compared to the current rhel version.
Okay, this is fixed in rawhide, closing.