Open Bug 2016896 Opened 8 months ago Updated 4 months ago

[KDE] HDR + Wayland = crash

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 147
defect

Tracking

()

UNCONFIRMED

People

(Reporter: priit, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(14 files)

193.16 KB, image/png
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
3.11 MB, application/octet-stream
Details
10.00 MB, application/octet-stream
Details
831.53 KB, application/octet-stream
Details
15.34 KB, application/x-7z-compressed
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

Turned on HDR via about:config to gfx.wayland.hdr = true.
(not sure if related, but 240Hz monitor... before when I ran the same monitor in 60Hz, I don't remember it crashing this bad... or maybe it was v146 back then.)

Actual results:

https://crash-stats.mozilla.org/report/index/937df160-5d44-4c94-93dc-76d7a0260212
https://crash-stats.mozilla.org/report/index/56ada3bf-44ef-4e50-a67f-89dcb0260212
https://crash-stats.mozilla.org/report/index/f1949c8b-2067-4176-a1bf-b5abe0260212
https://crash-stats.mozilla.org/report/index/915bdb8a-df8f-4654-8671-b59880260212

Expected results:

no crash in less than 30minutes.

Running it in Wayland native mode gfx.wayland.hdr = false is totally stable.
Or running it with xwayland with MOZ_ENABLE_WAYLAND=0 /usr/lib/firefox/firefox and with gfx.wayland.hdr = true is also totally stable, but then it's not exactly "Wayland and HDR", is it?

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Which KDE version do you run? Please try latest nightly with the HDR option enabled:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

Flags: needinfo?(priit)
Priority: -- → P3

KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1

Flags: needinfo?(priit)

Okay, please try latest nightly, run on terminal with MOZ_LOG="WidgetWayland:5,WidgetCompositor:5" env variables and attach the log here. You may need to run it redirected to a file like:

MOZ_LOG="WidgetWayland:5,WidgetCompositor:5" ./firefox -P profile > log.txt 2>&1

and attach the log.txt here.

with new empty profile didn't crash, but created me a 30GB log file for 20 minutes usage 🤦🏻‍♂️
Will try with my full profile again... but this logging is not good. I don't have this much disk space.

with my own profile it did become slower and slower and slower and then finally became unresponsive... until KDE asked, if I want to terminate unresponsive app or wait... waited 5 times and then terminated, which caused crash dialog popup, which I reported also. can't upload the requested log here, because it's 9.4GB and 93MB when compressed with 7zip ... and you have 10MB file limit here.

uploaded crash report:
https://crash-stats.mozilla.org/report/index/f0f381e8-d652-4eaa-a8b4-7ec910260226

Attached file nightly-log.7z.001 —
Attached file nightly-log.7z.002 —
Attached file nightly-log.7z.003 —
Attached file nightly-log.7z.004 —
Attached file nightly-log.7z.005 —
Attached file nightly-log.7z.006 —
Attached file nightly-log.7z.007 —
Attached file nightly-log.7z.008 —
Attached file nightly-log.7z.009 —
Attached file nightly-log.7z.010 —

Thanks. Does the latest nightly crash if you run it with gfx.wayland.hdr = true in your profile? (without any logging?).

Flags: needinfo?(priit)
Severity: -- → S3

Thanks for testing. Please run on terminal as:

MOZ_LOG="Dmabuf:5,WidgetWayland:5,WidgetCompositor:5" firefox 2>&1 | tail -n 10000000 > log.txt

and if you see the crash please attach log.txt file here. This command (tail) filters out all lines except the last ones so we'll get the crash data without flooding your disk.
Thanks.

Flags: needinfo?(priit)
Summary: HDR + Wayland = crash → [KDE] HDR + Wayland = crash

btw it worked yesterday about half an hour and idled perfectly fine overnight... and worked today like 2 more hours until crashed.

Thanks, will look at it.

Flags: needinfo?(stransky)

Do you still see it? If so, can you please run on terminal with MOZ_LOG="WidgetScreen:5" env variable and attach the log here?
Thanks.

Flags: needinfo?(stransky) → needinfo?(priit)

Looks related to screen color management so I'd need a screen log for it.
Thanks.

And how do I get this "screen log" exactly?

Flags: needinfo?(priit)

Run on terminal:

MOZ_LOG="WidgetScreen:5" firefox > log.txt 2>&1

and attach log.txt here.
Thanks.

Flags: needinfo?(priit)

the current nightly (153.0a1 (2026-06-11) (64-bit)) is so effd up, it's completely unusable -- I can't even move tabs around and in-between windows. WTF?? Instead of moving the tab inbetween other tabs, it just ALWAYS makes it to go into new window, so now after a little white I have like 30 windows open. I stopped the experiment until it becomes usable again.

Flags: needinfo?(priit)

Latest nightly should work again.
Thanks.

Flags: needinfo?(priit)

Right now running 154.0a1+20260618.1+h0e796bae8077-1.
Has not crashed yet. But the HDR was not "on" by default anymore... so I had to enable it.
gfx.color_management.hdr: false (default) => true
gfx.color_management.hdr.force_enabled: false (default) => true

With this HDR part seems to be working semi perfectly in youtube (only place I can think of to test this). Problem is somewhat seriously higher dropped frames. ... for example this video: https://www.youtube.com/watch?v=E7mIBeMJ7MA has given me so far 1441/68000 dropped frames.

(
Also as a sidenote, I had to reduce the HDR monitor refresh rate to 60Hz because reasons... ( https://gitlab.freedesktop.org/drm/amd/-/work_items/3547 ) I got it back working with kernel 6.18.7 when I reported the problem with firefox here with a patch provided by Andrei Amuraritei, but due to several major linux kernel vulnerabilities being exposed and fixed in past month I had to move forward to newer security fixed kernel, but there once again 240Hz doesn't play well at all with other monitors at 60Hz. 😿

And I do believe the 240Hz display might have been also catalyst for the firefox instability and crashiness... so until I can test it again on 240Hz mode, it's ... not firmly solved yet? 😅

Anyway I keep using nightly at 60Hz and maybe it just takes longer... well see.
)

Flags: needinfo?(priit)

anyway didn't crash after using 2 days. however it does become really sluggish and slow. in the end dropping like 2/3 of youtube frames for example. even in non hdr videos. also sluggish in other areas, like java/js games and so. compared then to the stable 152 firefox.

didn't crash, but the requested log anyway.
MOZ_LOG="WidgetScreen:5" firefox-nightly > nightly-log-2026-06-19e.txt 2>&1

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: