Firefox Is Going to Try and Ship with Wayland Enabled by Default

Original Article ↗ Hacker News Discussion ↗

Firefox’s plan to enable its native Wayland backend by default on Linux highlights the ongoing shift away from the decades‑old X11 display system. Commenters explain that most apps rely on toolkits like GTK or Qt to speak Wayland, but complex software such as browsers, Electron apps, and games expose edge cases around GPU acceleration, screen sharing, window positioning, and scripting tools. Many report smoother rendering, better HiDPI scaling, and improved security under Wayland, while others—especially Nvidia and older‑hardware users—still encounter instability and missing workflows, underscoring that X11 compatibility via XWayland will remain important for years.

What “Firefox with Wayland by default” means

  • On Wayland desktops, Firefox will talk Wayland directly instead of via the XWayland compatibility layer.
  • X11 users (e.g., Ubuntu 20.04 on Xorg) are unaffected; Firefox will still use X11 there.
  • Distros like Fedora and (GNOME on) Debian already default to Wayland Firefox via env vars such as MOZ_ENABLE_WAYLAND=1.

Wayland vs X11 basics

  • Both are display protocols between apps and a display server/compositor.
  • X11 is older, network‑oriented, includes drawing primitives; Wayland is buffer‑based and leaner.
  • Apps can still use X11 under Wayland via XWayland, but that can hurt scaling and visual quality.

Application and toolkit support

  • Most apps rely on GUI toolkits (GTK, Qt, Electron, SDL, etc.) which hide X/Wayland details.
  • Firefox uses its own rendering stack and needs explicit Wayland support, especially for video, hardware acceleration, and WebGL.
  • Some games and legacy apps may never be ported; they will rely on XWayland or native-Wayland WINE.

User experiences with Firefox on Wayland

  • Many report Firefox on Wayland has been stable “for years,” with good mixed‑DPI and touchpad pinch‑zoom support.
  • Others see intermittent crashes (e.g., when dragging tabs) or WebGL issues, sometimes tied to Nvidia.
  • Some users see no visible difference vs X; others notice smoother rendering and better scaling.

Performance, GPU, and hardware issues

  • Reports vary: some find Wayland smoother and less tear‑prone; others feel higher latency, especially on older laptops.
  • Nvidia is a recurring pain point: some Wayland compositors need patches; certain apps lose GPU acceleration; older GPUs or flaky drivers can make Wayland unusable.
  • Workarounds include forcing software rendering (LIBGL_ALWAYS_SOFTWARE), disabling GPU per‑app, or using specific compositors/patches.

Screen capture, sharing, and tooling

  • Early Wayland adopters often discovered it only when screen capture and hotkey tools broke.
  • Built‑in screenshot tools generally work; third‑party screen sharing/automation tools must adopt new, permission‑based protocols and are in various states of support.

X11 vs Wayland debate

  • Pro‑Wayland: better security (apps can’t trivially snoop keystrokes), cleaner design, fixes long‑standing X issues like tearing and scaling.
  • Pro‑X11: mature, “just works” for some workflows, rich CLI tooling (xrandr/xdotool/xwininfo), and fewer regressions on older or quirky hardware.
  • Critics of Wayland cite extension sprawl, verbosity, inconsistent compositor quality, and missing conveniences like reliable window-position persistence (expected to be compositor‑implemented).