GNOME Bugzilla – Bug 757568
Epiphany makes the Shell crash
Last modified: 2016-09-01 13:10:34 UTC
Looks like my Wayland session (Shell 3.19.1, Fedora Rawhide) has a systematic crasher: * launch `epiphany` (version 3.18.0 is good); * app’ menu -> “Bookmarks”; * “File” -> “Import bookmarks…”; * “Files” is selected; * try to “Import”. The Shell shouldn’t crash, whatever apps are doing. What informations could be useful for helping solving that?
By far the most useful thing you can provide for a crash is a reproducer, like you've done here. The next two things that you can provide are log messages - after reproducing the crash, if I look through my log messages with journalctl, the first thing I see going wrong is: Nov 04 08:07:13 localhost.localdomain gnome-session[2485]: ** Nov 04 08:07:13 localhost.localdomain gnome-session[2485]: mutter:ERROR:core/window.c:1355:meta_window_unmanage: assertion failed: (window->display->focus_window != window) So mutter (the backend to gnome-shell) hit an assertion failure, and crashed. The next thing I'd look for would be a backtrace filed by Fedora's abrt tool - so I look in /var/spool/abrt and see a directory: /var/spool/abrt/ccpp-2015-11-04-08\:07\:13-2519/ The reported_to file in that directory has https://retrace.fedoraproject.org/faf/reports/bthash/71381a956d10895088484a042d048d2f43079e9f (It didn't get combined with your report because it looks like I updated my gnome-shell but didn't reboot my system. Your report is probably one of those in: https://retrace.fedoraproject.org/faf/problems/bthash/?bth=04394aa0dc20f3f5dbd507a4914aa156f3fdb7c2&bth=bb24609f323a3b1c585b657270c914150dfe130b&bth=df57cb0aeb2c5f258cedafd8b01c28e1dc21f17b ) I've seen those crash reports - but had no idea what was causing them - it's not something you can figure out from the backtrace - so it's incredibly useful to have the reproducer.
Relevant part of Mutter debug output: FOCUS: Focusing default window since we're unmanaging W6 (Import Boo) FOCUS: Focusing MRU window FOCUS: Focusing workspace MRU window W4 (Bookmarks) FOCUS: Setting input focus to window W4 (Bookmarks), input: 1 take_focus: 0 FOCUS: W4 (Bookmarks) has W7 (Import Boo) as a modal transient, so focusing it instead. WINDOW_STATE: Removing W7 (Import Boo) from the calc_showing queue VERBOSE: Implement showing = 0 for window W7 (Import Boo) WINDOW_STATE: Hiding window W7 (Import Boo) FOCUS: Window W7 (Import Boo) is not showing, not focusing after all What happens here is that the code decides to focus the new "Import Bookmarks" window, which is a modal dialog for the parent of the old "Import Bookmarks" window, but because that window doesn't yet have an attached buffer, it doesn't focus it, nothing gets focused, and Mutter aborts because the focus is still on the wold "Import Bookmarks window, which is going away.
Created attachment 334597 [details] [review] window: Fix focus of unmappable modal transient's parent When a modal transient is unmanaging, most likely the parent of the modal transient should be focused. In Wayland, a MetaWindow is created when a shell surface role (like xdg_toplevel) is created, but a window cannot be shown until a buffer is attached. If a client would create two modal transients and make them both have the same parent, but only one get a buffer attached (i.e. shown), when unmanaging the modal transient that was showing, when finding a new focus candidate, the stacking code will ignore the not-to-be-shown buffer-less modal transient when finding a good candidate for focusing. In the case described here, this means it will find the parent of the unmanaging modal transient. This newly chosen candidate will then be passed to meta_window_focus(); meta_window_focus() will then try to find any modal transient to focus instead, will find the one without any buffer, then fail to focus it because it cannot be mapped, thus making meta_window_focus() not focus anything. Since meta_window_focus() didn't change any focus state, the assert in meta_window_unmanage() checking that the unmanaging window isn't focused anymore will be hit, causing mutter to abort. For now, fix this by checking whether the modal transient can actually be focused in meta_window_focus(). For X11 client windows, a window will be defined to be focusable always, but for Wayland client windows, a window will be determined focusable only if it has a buffer attached. In the future, we should probably do a more thorough refactorization of focus handling to get rid of any X11 - Wayland differences.
Review of attachment 334597 [details] [review]: makes sense
Attachment 334597 [details] pushed as 6c8f6af - window: Fix focus of unmappable modal transient's parent