[KDE] HDR + Wayland = crash
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
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?
Comment 2•8 months ago
|
||
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.
Comment 3•8 months ago
|
||
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.
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1
Comment 5•8 months ago
|
||
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
| Reporter | ||
Comment 10•8 months ago
|
||
| Reporter | ||
Comment 11•8 months ago
|
||
| Reporter | ||
Comment 12•8 months ago
|
||
| Reporter | ||
Comment 13•8 months ago
|
||
| Reporter | ||
Comment 14•8 months ago
|
||
| Reporter | ||
Comment 15•8 months ago
|
||
| Reporter | ||
Comment 16•8 months ago
|
||
| Reporter | ||
Comment 17•8 months ago
|
||
| Reporter | ||
Comment 18•8 months ago
|
||
Comment 19•8 months ago
|
||
Thanks. Does the latest nightly crash if you run it with gfx.wayland.hdr = true in your profile? (without any logging?).
| Reporter | ||
Comment 20•8 months ago
|
||
Updated•8 months ago
|
Comment 21•8 months ago
|
||
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.
Updated•8 months ago
|
| Reporter | ||
Comment 22•8 months ago
|
||
| Reporter | ||
Comment 23•8 months ago
|
||
| Reporter | ||
Comment 24•8 months ago
|
||
| Reporter | ||
Comment 25•8 months ago
|
||
btw it worked yesterday about half an hour and idled perfectly fine overnight... and worked today like 2 more hours until crashed.
Comment 27•5 months ago
|
||
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.
Comment 28•5 months ago
|
||
Looks related to screen color management so I'd need a screen log for it.
Thanks.
| Reporter | ||
Comment 29•5 months ago
|
||
And how do I get this "screen log" exactly?
Comment 30•5 months ago
|
||
Run on terminal:
MOZ_LOG="WidgetScreen:5" firefox > log.txt 2>&1
and attach log.txt here.
Thanks.
| Reporter | ||
Comment 31•5 months ago
|
||
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.
| Reporter | ||
Comment 33•4 months ago
|
||
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.
)
| Reporter | ||
Comment 34•4 months ago
|
||
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.
| Reporter | ||
Comment 35•4 months ago
|
||
didn't crash, but the requested log anyway.
MOZ_LOG="WidgetScreen:5" firefox-nightly > nightly-log-2026-06-19e.txt 2>&1
Description
•