After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757568 - Epiphany makes the Shell crash
Epiphany makes the Shell crash
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: wayland
3.18.x
Other Linux
: Normal critical
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-11-04 08:33 UTC by Arnaud B.
Modified: 2016-09-01 13:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window: Fix focus of unmappable modal transient's parent (2.89 KB, patch)
2016-09-01 11:09 UTC, Jonas Ådahl
committed Details | Review

Description Arnaud B. 2015-11-04 08:33:36 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?
Comment 1 Owen Taylor 2015-11-04 13:21:29 UTC
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.
Comment 2 Owen Taylor 2015-11-04 16:16:06 UTC
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.
Comment 3 Jonas Ådahl 2016-09-01 11:09:31 UTC
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.
Comment 4 Rui Matos 2016-09-01 13:08:17 UTC
Review of attachment 334597 [details] [review]:

makes sense
Comment 5 Jonas Ådahl 2016-09-01 13:10:30 UTC
Attachment 334597 [details] pushed as 6c8f6af - window: Fix focus of unmappable modal transient's parent