GNOME Bugzilla – Bug 711618
shell abort: mutter:ERROR:core/window.c:1748:meta_window_unmanage: assertion failed: (window->display->focus_window != window)
Last modified: 2014-10-16 09:49:03 UTC
Rawhide here: gnome-shell-3.11.1-1.fc21.x86_64 mutter-3.11.1-1.fc21.x86_64 I have the misfortune of using a java app - IPMIView, ftp://ftp.supermicro.com/utility/IPMIView/ Here are some reproducible(here) steps to get shell to crash when using it. - start the app - press the New connection button - press OK in the dialog - press the Close window mutter button - X - Press No on the "save configuration" prompt dialog .. kaboom... .. something from the log.... Nov 07 16:35:28 d2 gnome-session[2656]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x2200013 specified for 0x2200036 (Add a new ). Nov 07 16:35:33 d2 gnome-session[2656]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x2200013 specified for 0x2200036 (Add a new ). Nov 07 16:35:41 d2 gnome-session[2656]: ** Nov 07 16:35:41 d2 gnome-session[2656]: mutter:ERROR:core/window.c:1748:meta_window_unmanage: assertion failed: (window->display->focus_window != window) Nov 07 16:35:41 d2 gnome-session[2656]: gnome-session[2656]: WARNING: Application 'gnome-shell.desktop' killed by signal 6
*** Bug 704597 has been marked as a duplicate of this bug. ***
Can easily reproduce with another Java-based program (rsu-client, the standalone version of RuneScape applet). mutter 3.11.2-1-gca5d115 gnome-shell 3.11.2-8-gc85145d In addition to crashing gnome-shell/mutter, it causes overall weird behavior: When I click the window or Alt+Tab to it, it starts receiving input, but does not show up as focused (i.e. the titlebar still has the "unfocused" look). Pressing Alt+Tab again sometimes shows it as focused, sometimes doesn't (i.e. the switcher shows the previous app as still being active). The crash: After focusing the Java window (as above), start another program (e.g. gnome-terminal), then close it. Instead of moving focus back to the Java window, gnome-shell crashes every time with: Program terminated with signal 6, Aborted.
+ Trace 232785
Just for the record, Wine causes the same kind of crashes.
Seems like
Seems like Gnome 3.10.2 is also affected, see https://bugzilla.redhat.com/show_bug.cgi?id=1042773
This is fall-out from bug 710296 - the problem is that when we unmanage a window we *need* to move the focus away. If we select a globally active window (input=false, takes_focus=true) as the place to move the focus, we get this problem - since we don't actually change display->focus_window, we just send the window a message asking it to take the focus. Possibilities: * Don't ever select such a window as the destination of the focus when closing a window. This is probably a bad idea, since it breaks focus reversion to the ancestor of a modal dialog if that ancestor is globally active - the case we actually have here for IPMIView. * Go back to the code we used to have *in the case* where the current window is being unmanaged. If Mutter picks a "fake globally active client" like an GTK+-based OSK as the destination - that is a window that asks for WM_TAKE_FOCUS but then does nothing with it - then we end up with the no-focus-window focused instead of an app window, which isn't great, but OK.
Created attachment 264326 [details] [review] display: Don't leave focus on a window we are unmanaging when sending WM_TAKE_FOCUS Thanks for the IPMIView test case and detailed instructions! I noticed that focus also isn't getting displayed properly in IPMIView (and presumably all other Swing applications) - I'll file a separate bug/patch for that. ==== When we move focus elsewhere when unmanaging a window, we *need* to move the focus, so if the target is globally active, move the focus to the no-focus-window in anticipation that the focus will normally get moved to the right window when the target window responds to WM_TAKE_FOCUS. If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left on the no-focus-window, but there's no way to distinguish whether the app will respond or not.
*** Bug 720664 has been marked as a duplicate of this bug. ***
Created attachment 264479 [details] Simple test case for another reproducer The upstream bug 995785 has this same assertion failure, but it turns out that the *first* instance of it was filed before the introduction of the crash that the other patch fixes. Looking at it I think I figured out what was going on with that crash. (The crash is still new with 3.9.x - it was introduced when we landed the patches in bug 647706 in May.) This is a simple test case that creates a window and exits after 5 seconds. Run it as 'gjs exit.js' and then immediately grab the window and start moving it.
Meant to say *downstream* *Fedora* bug: https://bugzilla.redhat.com/show_bug.cgi?id=995785
Created attachment 264480 [details] [review] Be willing to unfocus the grab window when we are unmanaging it When we are unmanaging the grab window, we /need/ to unfocus it, so we shouldn't bail out early from meta_window_focus().
Review of attachment 264480 [details] [review]: Yep, this makes sense.
Review of attachment 264326 [details] [review]: I'm not too happy with the placement of the check (meta_display_request_take_focus, plus window != focus_window seems like an odd way to check for the Globally Active case, the only case where we have a "delayed focus"), but since this is how the patch by Dan Winship originally landed, I'm OK with it.
Created attachment 264488 [details] [review] display: Don't leave focus on a window we are unmanaging when sending WM_TAKE_FOCUS Here's a new version that puts the focus into meta_window_focus() - no point in leaving things in a way we both find a bit weird. === When we move focus elsewhere when unmanaging a window, we *need* to move the focus, so if the target is globally active, move the focus to the no-focus-window in anticipation that the focus will normally get moved to the right window when the target window responds to WM_TAKE_FOCUS. If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left on the no-focus-window, but there's no way to distinguish whether the app will respond or not.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6330186 is a Fedora 20 scratch build which includes the #710296 fix and both "Be willing to unfocus the grab window when we are unmanaging it" (attachment 264480 [details] [review]) and "Don't leave focus on a window we are unmanaging when sending WM_TAKE_FOCUS" (attachment 264488 [details] [review]). I'm not doing this as an 'official' F20 build for now as one of the patches is un-reviewed.
Pushed both patches to master/gnome-3-10/wayland - general approach of unreviewed patch was discussed with Jasper and I gave it some testing. Attachment 264480 [details] pushed as a42305e - Be willing to unfocus the grab window when we are unmanaging it Attachment 264488 [details] pushed as 0caf738 - display: Don't leave focus on a window we are unmanaging when sending WM_TAKE_FOCUS
(In reply to comment #16) > Pushed both patches to master/gnome-3-10/wayland - general approach of > unreviewed patch > was discussed with Jasper and I gave it some testing. The issue we came up with was when we were unmanaging a No Input window without a frame, I believe, and I wanted meta_display_focus_default_window to take a needs_focus boolean, I think.
OK, I'm sending a -6 build to F20 with all three patches and will edit my update.
https://admin.fedoraproject.org/updates/mutter-3.10.2-6.fc20
There's an interesting report in the downstream bug: "I'm not getting crashes anymore with mutter 3.10.2-6, but I'm having problems with window selection, specifically fullscreen Wine games (League of Legends), which I was not having before. If I Alt-Tab or select the application from the app. list, it will flash like it's focused, then be instantly unfocused. Sometimes it will end up with mouse focus, sometimes it will be 'fall through', with clicks going to windows below it. If I then activate it again (by doing either the Alt-Tab or the app selection, whichever I had not used previously) the windows gets focus, but occasionally the mouse focus will stay bugged. With mutter 3.10.2-2 I can focus the windows consistently every time, but *unfocusing* is inconsistent and sometimes will not bring up the selected application." If anyone's having trouble keeping the Fedora build numbers straight: * 3.10.2-2 had none of the patches for this bug or #710296 * 3.10.2-3 changed something unrelated, I believe * 3.10.2-4 had the patch for #710296 but no patch for this bug * 3.10.2-5 had the #710296 patch reverted (so effectively identical to -3 - different from -2, but no different as regards these bugs AFAIK) * 3.10.2-6 has the patch for #710296 and both patches for this bug
*** Bug 724924 has been marked as a duplicate of this bug. ***
*** Bug 724845 has been marked as a duplicate of this bug. ***