## What happened

Installed Zen via `omarchy install browser zen` on a fresh Omarchy 4.0.4 NVIDIA laptop. Launching Zen (from the app launcher or a terminal) starts the process, spawns content processes, takes the profile lock, and then sits forever with no window. `hyprctl clients` never lists a `zen` client. Nothing is logged by Zen, Hyprland, or the portals.

Expected: the browser window appears.

## Root cause (verified)

A gdb capture of the hung parent process shows the deadlock:

- **Renderer thread** is blocked inside `/usr/lib/libnvidia-egl-wayland2.so.1` in `wl_display_dispatch_queue()`, waiting for a Wayland event that never arrives.
- **Main thread** is inside GTK's draw handler, looping on a timed `ConditionVariable::wait_for` in libxul waiting for that renderer's first frame.
- Zen's own `MOZ_LOG=WidgetWayland:5` shows the toplevel was shown and Hyprland sent an `xdg_toplevel.configure`, but Zen never acks it with a buffer, so Hyprland never maps the window.

`libnvidia-egl-wayland2.so.1` is the new NVIDIA EGL Wayland external platform from the `egl-wayland2` package (1.0.2-1). It is a hard dependency of `nvidia-utils` 610.57.04, and its platform file `09_nvidia_wayland2.json` sorts ahead of the classic `10_nvidia_wayland.json`, so every EGL-on-Wayland client on the NVIDIA driver now goes through it.

## Reproduction matrix (all on the same machine, same profile unless noted)

| Launch variant | Window appears? |
|---|---|
| `zen-browser` (default) | no |
| clean temporary profile | no |
| `MOZ_DISABLE_WAYLAND_PROXY=1` | no |
| `__NV_DISABLE_EXPLICIT_SYNC=1` | no |
| `__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS=<dir without 09_nvidia_wayland2.json>` (classic egl-wayland 1.1.22) | **yes** |
| `__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json` | yes |
| `gfx.webrender.software=true` | yes |
| `MOZ_ENABLE_WAYLAND=0` (Xwayland) | yes |

So Hyprland, the portals, the profile and Zen's config are fine; only the egl-wayland2 platform path deadlocks. Chromium and foot are unaffected because they don't use the EGL Wayland platform. Firefox and LibreWolf share the same widget code and are expected to hit this too (not tested here, only Zen is installed).

## Why I'm filing this here

The underlying bug belongs to NVIDIA (egl-wayland2) and/or Mozilla's Wayland widget, and I'll point it there as well. But Omarchy is the layer that:

- installs `nvidia-utils` on NVIDIA machines (`install/hardware/nvidia.sh`), which now drags in `egl-wayland2`;
- owns the per-session NVIDIA environment (`default/hypr/nvidia.lua`, which already sets `NVD_BACKEND`, `LIBVA_DRIVER_NAME`, `__GLX_VENDOR_LIBRARY_NAME`);
- offers Zen and Firefox as first-class browsers in the Omarchy menu.

Result: on a current Omarchy NVIDIA install, two of the menu's browser choices silently don't start.

## Possible mitigation on Omarchy's side

`nvidia.lua` could export `__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS` pointing at an Omarchy-shipped directory that contains the NVIDIA platform JSONs minus `09_nvidia_wayland2.json`, until egl-wayland2 or Firefox is fixed. That is what made Zen work in the matrix above. Trade-off: it pins the whole session to the classic egl-wayland, so other EGL clients lose whatever wayland2 brings. A narrower alternative is to wrap only the Firefox-family `.desktop` launchers with that variable (Omarchy already tags them in `apps/browser.lua`).

## System

- Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2-2
- Alienware m18 R2, NVIDIA GeForce RTX 4080 Laptop GPU (dGPU is the only DRM device; external 3440x1440 HDMI monitor, scale 1.25)
- nvidia-open-dkms / nvidia-utils 610.57.04-1, egl-wayland2 1.0.2-1, egl-wayland 4:1.1.22-1, mesa 26.2.2-1, gtk3 3.24.52-1
- zen-browser-bin 1.22.2b-1 (Firefox 156 base, build 20260915091052)

Happy to attach the full 125-thread gdb backtrace or the WidgetWayland log if useful.

Filed by Claude Fable 5.1 via Claude Code.