GNOME Bugzilla – Bug 759297
wayland: assertion failed in meta_window_unmanage()
Last modified: 2016-01-06 18:01:54 UTC
Created attachment 317109 [details] Simple reproducer program Summary: mutter/gnome-shell will fail on a assertion failed when using the attached reproducer. The reproducer updates the transient relationship between windows whic hseems to confuse mutter focus handling. Steps to reproduce: 1. Save and build the attached reproducer $ gcc -o testdialog-mutter testdialog-mutter.c `pkg-config --libs --cflags gtk+-3.0` 2. Run the reproducer 3. Iconify one of the normal windows, the two dialogs will hide as well 4. close the other remaining window Actual result: mutter aborts with: mutter:ERROR:core/window.c:1355:meta_window_unmanage: assertion failed: (window->display->focus_window != window) Program received signal SIGABRT, Aborted. Expected result: The app closes and mutter survives Additional data: I reckon this is not the same as bug 751715 because the patch attached there attachment 306402 [details] [review] has been merged as commit 6c05eb58 and yet I can still crash mutter with the given reproducer. gdb shows the following: 0 0x00007fffe9fa2a98 in raise () from /lib64/libc.so.6
+ Trace 235806
1350 meta_topic (META_DEBUG_FOCUS, 1351 "Unmanaging window %s which doesn't currently have focus\n", 1352 window->desc); 1353 } 1354 1355 g_assert (window->display->focus_window != window); 1356 1357 if (window->struts) 1358 { 1359 meta_free_gslist_and_elements (window->struts);
Created attachment 318344 [details] [review] window: Re-evaluate window visibility when making it transient In case a window is hidden when we're ordered to make it transient to a different parent we must re-evaluate its visibility status or we'll get into an inconsistent state where the parent is visible and the child isn't. -- When a main window of this reproducer gets minimized, its transients are hidden as expected. But when it then makes the dialogs transients to the other still visible window we don't show the transients. This is, I argue, the root problem. The assertion is then hit if the visible window is unmanaged because when we ask the stack for the next window in the stack to be focused it returns the hidden dialog but since it's hidden we refuse to focus it and thus we hit the assertion. This obviously doesn't happen anymore if the dialog is shown as soon as it's set transient as in this patch.
Review of attachment 318344 [details] [review]: Makes sense.
Attachment 318344 [details] pushed as 3a2cd33 - window: Re-evaluate window visibility when making it transient