Chromium, Edge, Google Chrome and PWA Apps close on Workspace move (Super+Shift+number e.g 2)

[ipsonuser]

Just did the update of Omarchy.
On return, the function that I quite enjoyed of moving apps to other windows broke down for anything browser based except firefox.

When Chromium, Microsoft Edge, Google Chrome is opened and I do SUPER+SHIFT+2 for 2nd workspace the app / browser closes down completely.

The same behavior is not observed on native apps, or firefox. They switch as expected.
This has been introduced only today when I did omarchy update.

my monitors config:

Back to defaults (auto placement / auto offsets)

env = GDK_SCALE,2
env = QT_SCALE_FACTOR,2

monitor = DP-1,preferred,auto,2
monitor = DP-2,preferred,auto,2

workspace = 1 monitor:DP-1
#env = GDK_SCALE,2

NVIDIA 4060

not sure if something I Can do to stop it , fix it
Not urgent , not imporant :)

Cheers

[TSDAdam]

Same thing for me. My monitors.conf:

env = GDK_SCALE,1
monitor=,preferred,auto,1

[ipsonuser]

I spent some time with ChatGPT on this,
Single Line Solution.. start chromium from Terminal with:

chromium --ozone-platform=x11 --disable-gpu --use-gl=swiftshader --enable-unsafe-swiftshader

Below, is ChatGPT version to explain why this is happening.
Please note, Im not a coder, software developer but I do work with IT (IT Network Security) for good bit of time.
The language is readable to me, but Im not competent to tell if this is true or false.

After your system update, Chromium-based browsers (Chromium, Chrome, Edge, PWAs) started closing instantly when moved between monitors or workspaces in Hyprland 0.51.1 (Wayland).
Other applications (Firefox, terminals, etc.) were unaffected.

This is not a crash of Hyprland or Chromium itself — it’s a mismatch between how Hyprland handles window reparenting and how Chromium manages its Wayland surfaces and GPU process.

Chromium uses a framework called Ozone to abstract the display system.
Under Wayland:
Each browser window is an xdg_toplevel surface.
The actual browser content is drawn via GPU through a Wayland EGL context.
Chrome’s window decorations (titlebar, borders, etc.) are drawn by Chrome itself using Wayland subsurfaces.
So when you see that cyan/blue frame, that’s Chromium’s client-side decoration layer — not a native Hyprland border.

When you press SUPER + SHIFT + 2, Hyprland:
Temporarily unmaps (unparents) the window from its current output.
Sends a xdg_toplevel.destroy for that surface.
Immediately creates a new surface for the same window on the destination output.
This is how Hyprland keeps animations smooth and transitions atomic — but it assumes the application will gracefully rebind its Wayland surface when that happens.

Since Chromium 128+, the Ozone Wayland backend changed how it interprets a destroy event:
Chromium assumes that xdg_toplevel.destroy means the compositor wants this window gone for good.
It tears down its entire EGL and GPU context.
The GPU process notices the lost context, throws a segmentation fault, and terminates.
Because Chromium’s GPU process is shared across all browser windows, all Chromium-based windows close simultaneously.
--ozone-platform=x11
Forces Chromium to run under XWayland, bypassing Wayland’s xdg_toplevel protocol entirely.
Hyprland just treats it as a simple X11 window.
No destroy/reparent messages occur → no crash.
⚙️ --disable-gpu --use-gl=swiftshader
Tells Chromium to:
Skip the hardware-accelerated GPU process.
Render everything in software using SwiftShader (a software OpenGL implementation).
With this, even if something odd happens to a surface, the GPU process doesn’t die — it’s all CPU-based and sandboxed per window.
That’s why:
The individual window may still close if Hyprland sends destroy.
But other windows and PWAs survive, because there’s no shared GPU crash.

[izidorome]

#2184

[d-cas]

@hjanuschka fixed it upstream and #2394 should fix things in the mean time. Cheers