Skip to content

fix: gnome 51 unready window crash - #588

Open
ikaru5 wants to merge 3 commits into
forge-ext:mainfrom
ikaru5:fix/gnome51-unready-window-crash
Open

ikaru5 wants to merge 3 commits into
forge-ext:mainfrom
ikaru5:fix/gnome51-unready-window-crash

Conversation

@ikaru5

@ikaru5 ikaru5 commented Oct 22, 2026 •

Copy link
Copy Markdown

Problem

On GNOME Shell 51, opening some apps (reliably Google Chrome) crashes the whole
shell (SIGSEGV) and logs the user out. Backtrace ends in
meta_window_set_unmaximize_flags called from GJS, preceded by:

meta_window_move_resize_internal: runtime check failed: (priv->is_ready)

Forge unmaximizes and positions new windows from a fixed 200 ms timer. Slow
clients aren't configured yet at that point, and mutter 51 crashes on geometry
changes to such windows.

Fix

  • Windows from window-created are marked as awaiting their first frame and
    laid out once the actor emits first-frame.
  • move() and _liveResizeNeighbors() (which calls move_resize_frame()
    directly) skip those windows.
  • Only unmaximize windows that are actually maximized, via
    get_maximize_flags() on GNOME 49+ (pre-49 fallback kept).

Testing

  • GNOME Shell 51.0 / mutter 51.0, Wayland, Arch (CachyOS), laptop + external monitor
  • GNOME Shell 50.5, Wayland, Bluefin (Fedora 44 Silverblue)
  • Before: opening Chrome crashed the shell every time. After: Working every time

Kirill Kulikov and others added 2 commits October 22, 2026 14:43
On GNOME Shell 51 opening some apps (reliably Google Chrome) crashed the
whole shell with SIGSEGV in meta_window_set_unmaximize_flags, preceded by
"meta_window_move_resize_internal: runtime check failed: (priv->is_ready)".

Forge unmaximized and positioned new windows from a fixed 200 ms timer.
Slow-starting clients are not configured by then, and mutter 51 no longer
tolerates geometry changes on such windows.

- Mark windows from "window-created" as awaiting their first frame and
  render them once the actor emits "first-frame".
- Skip those windows in move() and in the live-resize neighbour layout,
  which calls move_resize_frame() directly.
- Only unmaximize windows that are actually maximized, using
  get_maximize_flags() on GNOME 49+.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With "make -j<n>" the prerequisites of "build: clean ..." run
concurrently, so "clean" can delete schemas/gschemas.compiled right
after it was compiled. The installed extension then fails to load with
"gschemas.compiled ... not found". Serialize the Makefile.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ikaru5

ikaru5 commented Oct 22, 2026

Copy link
Copy Markdown
Author

Make the Makefile safe for parallel make (Commit 55c5cb4)

With make -j<n> (e.g. CachyOS ships alias make="make -j$(nproc)"), the
prerequisites of build: clean ... run concurrently. clean then deletes
schemas/gschemas.compiled right after it was compiled, and the installed
extension fails to load with "gschemas.compiled ... not found".

Adds .NOTPARALLEL:. The build only takes seconds, so serializing it costs
nothing.

@ikaru5 ikaru5 changed the title Fix/gnome51 unready window crash fix: gnome 51 unready window crash Oct 22, 2026
Meta.MaximizeFlags.NONE only exists since mutter 51. On GNOME 49 and 50
it is undefined, so the check in _unmaximize() was always true and
called set_unmaximize_flags(0) for windows that are not maximized.
Mutter 50 asserts that at least one direction is set and aborts the
shell (seen on Bluefin, GNOME 50.5, right after login).

Compare against 0 instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ikaru5

ikaru5 commented Oct 22, 2026

Copy link
Copy Markdown
Author

Found a regression on GNOME 50.5 (Bluefin): Meta.MaximizeFlags.NONE only exists
since mutter 51. On 49/50 it is undefined, so _unmaximize() called
set_unmaximize_flags(0), which mutter 50 asserts against (SIGABRT right after login).
Pushed 1260b39, which compares against 0 instead.

Tested on GNOME 50.5 / Bluefin and GNOME 51.0 / Arch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant