Closed Bug 1986254 Opened 1 year ago Closed 1 year ago

Firefox slows down significantly when private mode invoked

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Version:
Firefox 142
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1667748

People

(Reporter: lruzicka, Assigned: stransky, NeedInfo)

References

Details

Attachments

(4 files)

firefox.txt
141.22 KB, text/plain
Details
The content of about:support
174.47 KB, text/plain
Details
Crashes reported to console from the plain binaries.
45.35 KB, text/plain
Details
bunch of apparent renderer errors and an indication that firefox fell back to software rendering
36.84 KB, text/plain
Details
Attached file firefox.txt —

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

Steps to reproduce:

Recently, I have seen Firefox slowing down significantly in web rendering when I tried to start a new private window. The content of the pages would only show in areas where I would hover the mouse cursor (similar to painting in graphical apps), or it would be shown if I started moving or resizing the window.
After a while, the situation settles and everything seems to work normally. However, there are errors in journalctl, see below.
I can reproduce this on version 141 and 142. Chromium works normally.

Reproducible: Always

Steps to Reproduce:
1.Open several panels in FF and switch between them -> should work fine.
2.Open a new private window -> the private window does not load properly, not do the older tabs when navigating to them, you need to brush your mouse over it to "paint" the content or resize the windows.
3.After some time, the situation gets better.

Actual results:

Expected Results:
No problems should be seen.

Expected results:

Expected Results:
No problems should be seen.

Flags: needinfo?(stransky)

I don't see any security implication here, please remove the security flag.

Please attach your about:support page.

Please test Mozilla binaries with clean profile:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(stransky) → needinfo?(lruzicka)
Group: core-security
Flags: needinfo?(lruzicka)

I do not know why Security is set, I did not set anything like that and I do not see where I would remove it?

With a clean profile, I have not seen these errors for approximately 30 minutes of testing.

I have been seeing exactly the same thing as Lukas on my main system (an HP Omnibook Ultra 14, AMD Strix Point). It doesn't have anything to do with private mode, though. It's triggered, AFAICT, by certain page content - I think pages with heavy graphical elements, or maybe video, or something. I didn't yet pin it down precisely but it's a real thing for sure. So far I've just been quitting and restarting the browser when it happens.

I also found that Google Meet reliably crashed (the tab or the whole browser) when I tried to use it in Firefox. It was fine on Chromium. Unfortunately I couldn't get a useful backtrace - coredumpctl gdb processed the dump and installed a bunch of debuginfo, but still gave me a basically empty traceback. I don't know why.

Which screen resolution do you use? Is that really 6K?

"failureId": "wr_window_new: MaxTextureSize_POST",

may be related to maximal allowed texture size which may be 4K.

Flags: needinfo?(lruzicka)

May be also related to actual HW (AMD Strix Point) which is quite new. If the same Firefox version works in F42 and it's broken in rawhide, I'm not sure the bug is in Firefox itself.

Can't speak for Lukas, but I have a 4K external display and a 2K laptop display, so the total is 6K. Though all my Firefox windows are usually on the 4K head.

(In reply to Adam Williamson from comment #9)

Can't speak for Lukas, but I have a 4K external display and a 2K laptop display, so the total is 6K. Though all my Firefox windows are usually on the 4K head.

And is the only difference between Firefox versions the Fedora version? Can you try the same Firefox version on Fedora 42? Because from the log it looks like gfx driver issue.

Flags: needinfo?(adamw)

I could rebase to F42 I guess. I'll try and find some time to fiddle with it this week. I did think it might be related to kernel 6.17, but then, it's only Firefox that seems to have issues...

Flags: needinfo?(adamw)

(In reply to Adam Williamson from comment #11)

I could rebase to F42 I guess. I'll try and find some time to fiddle with it this week. I did think it might be related to kernel 6.17, but then, it's only Firefox that seems to have issues...

That's pretty much possible, may be related how the drivers are used etc.

(In reply to Adam Williamson from comment #9)

Can't speak for Lukas, but I have a 4K external display and a 2K laptop display, so the total is 6K. Though all my Firefox windows are usually on the 4K head.

I only have one 4K display connected to the computer (Framebox desktop) with no other external devices.

Flags: needinfo?(lruzicka)

With the latest version 142.0.0.1-1, I cannot trigger this just by opening the private mode, but I could trigger this with rewardzone.redhat.com, where the content might be shown in "overlays" instead of normal pages and spending some time trying to see what's available caused the behaviour we are talking about.

(In reply to lruzicka from comment #13)

(In reply to Adam Williamson from comment #9)

Can't speak for Lukas, but I have a 4K external display and a 2K laptop display, so the total is 6K. Though all my Firefox windows are usually on the 4K head.

I only have one 4K display connected to the computer (Framebox desktop) with no other external devices.

Okay, I guess you use a screen scale then (125%?)

As a workaround you may try to set widget.wayland.fractional-scale.enabled to true at about:config and restart Firefox. It reduces the textures/framebuffer sizes for fractionally scaled displays.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #15)

(In reply to lruzicka from comment #13)

(In reply to Adam Williamson from comment #9)

Can't speak for Lukas, but I have a 4K external display and a 2K laptop display, so the total is 6K. Though all my Firefox windows are usually on the 4K head.

I only have one 4K display connected to the computer (Framebox desktop) with no other external devices.

Okay, I guess you use a screen scale then (125%?)

You are guessing correctly. I am using it on 125%. Let me see if the workaround works for me.

Yes, the workaround looks promising.

Bug 1731895 / Bug 1985720 is related - we report too big screen sizes on fractional scaling. 100% and 200% scale works correctly but 125-175 are using bigger framebuffer and scales that down then. But it also depends on actual HW how the buffer handles, I haven't seen issues on Intel/AMD yet.

ah, yeah, I also use 125% screen scaling. Will try that workaround.

The workaround seemed to help for a while, but today I hit the bug (broken/delayed display refreshes of the Firefox window) several times again. However, I was on the same boot this whole time. I've just rebooted to a rather newer kernel 6.17 snapshot (rc4 vs. rc2 before). I'll see if that makes any difference.

I can confirm what Adam is saying. The day before yesterday, the workaround kept me from having FF issues for the rest of the day, but yesterday it returned to problems, and more over I got real Firefox crashes (it stopped working and suggested to report the crash, which I did through the interface). Also, the chat.fedoraproject.org tab was crashing as a tab quite frequently and I had to close Firefox and reopen it to be able to access the chat. Otherwise the tab would keep crashing all over again.

Things have been OK since my reboot until just now, when I tried to view https://intracorphomes.com/gardena/amenities . That caused the bug to kick in pretty badly. I did some Google Meet calls earlier which worked fine, though.

If you see any crashes please post crash ID here:
https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_Mozilla_crash_reporter

Also please try to use non-scaled display (but widget.wayland.fractional-scale.enabled should mitigate that).
Thanks.

Please try plain Mozilla binaries in case we're hitting compiler/toolchain bug here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries

With the binaries downloaded from Mozilla directly, the problem is the same. I have always used the crash reporter when Firefox asked me to and I used it when the plain binaries failed, too.

1bad3dd6-ba0a-61f1-895d-4d6e0d224a67
287fc4d2-4a8f-f173-6ade-6d7fb529e238
bp-ca285b81-afda-41d9-85ac-fc50e0250903
bp-31b78bfc-7c7f-477e-b4cf-83ba40250903
bp-bfa51a4c-fffc-49b5-bea5-d0b190250901
bp-a293bf30-930b-4545-8dbf-49d3a0250901
bp-72fd21f5-41d8-4edd-b203-081630250905

These are crashes I have reported in the last couple of days.

Flags: needinfo?(lruzicka)

Those ale mostly crashes at libgallium-25.1.4.so - please report that backtraces at https://gitlab.freedesktop.org/mesa/mesa/-/issues

Unfortunately still seeing this with kernel 6.17.0-0.rc5.42.fc43.x86_64 and firefox-142.0.1-1.fc43.x86_64 . The 'broken refresh' problem happened pretty soon after boot this latest time. There's no associated crash or kernel messages from amdgpu, but I *do* see some interesting Firefox messages in the journal: ```

Unfortunately still seeing this with kernel 6.17.0-0.rc5.42.fc43.x86_64 and firefox-142.0.1-1.fc43.x86_64 .

The 'broken refresh' problem happened pretty soon after boot this latest time. There's no associated crash or kernel messages from amdgpu, but I do see some interesting Firefox messages in the journal. See attachment.

You're keep posing the same info again and again. I don't have this hardware so I can't do anything here. If you really want to get it fixed, then:

  1. Test it's Fedora 43 issue only - i.e. downgrade to Fedora 42 and test it. We need to check if it's Fedora 43 specific issue.
  2. Report that to MESA. It's obviously AMD drivers bug. If not, they'll tell us.

If you fail to do such steps Firefox may disable HW acceleration on AMD Strix Point by default and you'll go with SW fallback.

Flags: needinfo?(adamw)
Flags: needinfo?(lruzicka)

I fail to understand why it's not reported at MESA yet. Do you really want to get fixed or not?

We do, but unfortunately we do not have just this one bug and creating a new issue from scratch takes time. I am on it now.

Flags: needinfo?(lruzicka)

The issue is now reported with Mesa

https://gitlab.freedesktop.org/mesa/mesa/-/issues/13877

Like the others, as I mentioned in https://bodhi.fedoraproject.org/updates/FEDORA-2025-2def98c15c , I'm also seeing webrender frequently fail and fall back to software rendering after a cycle of repeated device resets, although with an older AMD Bonaire discrete GPU using the amdgpu driver. As I mentioned at the link above, this has been happening since updating to Fedora 43 on 29 August 2025, with multiple kernels from both the 6.16.* and 6.17.0-rc* series, and with mesa 25.1.4, 25.2.1, and 25.2.2. It happens on multiple Fedora wayland-based desktops, and does not occur with zink. It did not happen with Fedora 42. The problem can be triggered, fairly reliably, by attempting to resize or close Firefox windows, or when selecting locations while downloading files.

Duplicate of this bug: 1989579
See Also: 1989579 →

So here's a fun turn-up: the report made its way all the way down to the amdgpu kernel driver (we found a specific kernel commit without which it doesn't happen), but amdgpu guys are pointing the finger...all the way back up at Firefox (and glycin):

https://gitlab.freedesktop.org/drm/amd/-/issues/4568#note_3106823

apparently Firefox (possibly is doing something it shouldn't with OpenGL, via glycin-image-rs. I don't think this is a Fedora customization.

Flags: needinfo?(adamw)

Glycin is used because it's the primary image loader for GDK-PixBuf, which is used by GTK3. Fedora 43 enables Glycin, and Arch Linux did so for the still-in-testing GNOME 49 until about two hours ago, when I disabled it because of this issue.

right, and that explains why we don't see the bug on F42 as well.

Thanks for filing a Bug for this tricky combination of issues. We'll discuss in triage and see what we can do in Firefox to mitigate.

Blocks: gfx-triage
Severity: -- → S2
Priority: -- → P2

Bug 1959645 is a possible regressor.

If this indeed works, then Firefox could also fix this by consistently setting CLOEXEC for its file descriptors, which it currently doesn't. This might still be worth doing to prevent the problem reappearing if another source of unexpected forks sneaks into Firefox.

Jed, do you think it's actionable to our side? To create fd's with CLOEXEC by default?

Flags: needinfo?(jld)

Christian from the AMDGPU driver here. Adding a few thoughts which might help.

Well setting CLOEXEC on the fd is clearly a good idea. Question is how do you open the fd without CLOEXEC in the first place? Most libraries dealing with Linux kernel drivers set this flag as standard by now.

Then another question is how is Glycin actually using the fd passed into the child process? I want to make sure that neither amdgpu nor Mesa is doing anything wrong here. An strace of the involved processes would be helpful.

Thanks in advance,
Christian.

Depends on: 1990162

Bug 1667748 may be related too.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #48)

There's dmabuf related open call here:
https://searchfox.org/firefox-main/rev/c2e3c0aea49fb45082efdc129e79f84df7a07f48/widget/gtk/DMABufDevice.cpp#256

All open() calls:
https://searchfox.org/firefox-main/search?q=symbol:open&redirect=false

Thanks, but that unfortunately doesn't help.

The real question is how the same FD ends up being used in both parent and child process. Even without CLOEXEC that shouldn't happen.

Taking out of triage, provisionally assigning to stransky. Feel free to bounce it back if this needs a different owner.

Assignee: nobody → stransky
No longer blocks: gfx-triage

Was told by Fedora folks that Bug 1667748 fixed it.

Yeah, it seems to be fixed for me.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1667748
Resolution: --- → DUPLICATE

I have a ThinkPad with an AMD onboard GPU and am seeing a similar problem with Thunderbird 143.0.1, as reported in Bug 1991771. Is this also a duplicate?

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

Attachment

General

Creator:
Created:
Updated:
Size: