https://bugs.kde.org/show_bug.cgi?id=525096
Bug ID: 525096
Summary: glitches Firefox
Classification: Plasma
Product: kwin
Version First 6.7.4
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Summary
Firefox's Wayland HDR color-management path (gfx.wayland.hdr, which uses the
wp_color_manager_v1 protocol to describe surface color space/transfer function
to the compositor) causes visible graphical corruption in Firefox's own UI
chrome and in-page content — while video playback itself remains unaffected —
when running under KWin/Wayland. Disabling gfx.wayland.hdr in Firefox
eliminates the corruption entirely with no other change to the system.
This is likely related to a previously observed hard crash on this same code
path: with gfx.wayland.hdr enabled, playing HDR-tagged video content (e.g.
certain YouTube videos) crashes Firefox with:
GraphicsCriticalError: [GFX1-]: (kde) Wayland protocol error: [destroyed
object]: error 3: unsupported named transfer function
MozCrashReason: (kde) [destroyed object]: error 3: unsupported named transfer
function
The generic UI corruption described here appears to be a milder/non-fatal
manifestation of the same underlying protocol negotiation issue — sometimes it
results in a hard protocol-error disconnect (the crash above), sometimes in
silent visual corruption instead.
System information
KDE Plasma, Wayland session
AMD Radeon RX 7800 XT (RDNA3, gfx1101), Mesa 26.1.5 through 26.1.7 and mesa-git
(26.3.0-devel) all affected — ruling out this being a Mesa version-specific
issue
Firefox 153.x (release channel)
Dual monitor setup (one HDR-capable, one not) — corruption occurs regardless of
which monitor is active or whether HDR is enabled on the display itself
Symptom description
With gfx.wayland.hdr=true (Firefox default/enabled on recent versions where the
compositor advertises HDR support), Firefox's own UI (tab bar, bookmarks bar,
page text/buttons) and browser-native controls intermittently show block-style
graphical corruption.
Video frame content itself is never affected — even fullscreen or windowed
video playback renders cleanly. Only the surrounding UI, including the video
player's own overlay controls (play/pause/volume/fullscreen bar), is affected.
This strongly suggests video content is composited via a separate hardware
overlay path exempt from the color-managed surface description, while
everything else (including video controls, which are drawn by the
page/WebRender, not the overlay) goes through the affected path.
Corruption is isolated per top-level window: with two Firefox windows open
simultaneously on the same monitor, one can show corruption while the other
renders cleanly at the same time.
Setting gfx.wayland.hdr=false in about:config eliminates the corruption
completely, with no other change needed.
The issue reportedly started appearing recently despite gfx.wayland.hdr having
been enabled for an extended period without problems — suggesting a recent
change (in KWin, Mesa, or the protocol negotiation) altered
previously-tolerated behavior into visibly broken behavior, rather than the
flag itself being newly enabled.
Additional data point
The same underlying protocol also produces a related but distinct symptom on
Hyprland (wlroots-based compositor, unrelated codebase to KWin): video playback
on Hyprland shows a strong red color-cast across the entire frame for standard
video players, while a simpler embedded player (YouTube Shorts) renders
correctly. This suggests the wp_color_manager_v1 / HDR negotiation between
Firefox and Wayland compositors is fragile in general, with different
compositors failing in different ways (KWin: hard crash on specific content, or
this milder UI corruption; Hyprland: color misinterpretation).
Cross-references
Related Mesa/drm-amd investigation (extensive exclusion testing ruling out
firmware, kernel, GPU voltage/overclock, VRAM, Mesa version, and other
GPU-level causes before this was isolated): [link to your
gitlab.freedesktop.org/drm/amd issue here]
This may also warrant a Firefox-side bug report regarding how gfx.wayland.hdr
handles a compositor's imperfect/partial support of the color-management
protocol (falling back gracefully instead of triggering visible corruption or a
protocol-error crash).
Happy to provide dmesg/journalctl output, a screen recording of the corruption,
or test any patches/debug builds.
--
You are receiving this mail because:
You are watching all bug changes.
