Open Bug 2027480 Opened 2 months ago Updated 2 days ago

Firefox 149 startup hangs on Linux with hardware acceleration enabled

Categories

(Core :: Graphics: WebRender, defect, P1)

Product:
Core
Component:
Graphics: WebRender
Version:
Firefox 149
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: jan, Assigned: stransky)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

support-info.txt
64.53 KB, text/plain
Details
Attached file support-info.txt —

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

Steps to reproduce:

  1. Ensure "Use recommended performance settings" is enabled
  2. Update Firefox to 149
  3. Start Firefox

Actual results:

The process is running, but no window is shown, and there is no output on the terminal. Starting in Safe Mode and disabling "Use recommended performance settings" and "Use hardware acceleration when available" makes it start correctly again. Downgrading to 148 (and restoring a profile backup) also makes it work again without disabling the options.

This is on Linux Wayland/Sway with Intel Arc graphics, but it also seems to affect other cards (although that person apparently gets a blank window at least): https://askubuntu.com/questions/1565175/firefox-149-hangs-on-startup-unless-i-disable-hardware-acceleration

Expected results:

Firefox should start normally. If there is an issue with hardware acceleration it should automatically disable 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

Yeah, I'm the one who made that Ask Ubuntu post. I'm also experiencing this problem on Ubuntu 25.10 with an Geforce 1080 Ti with the Nvidia 580 drivers. I've reproduced the behavior with both the Firefox snap and the tarball directly from Mozilla, so that doesn't seem to make any difference.

Potentially worth mentioning that with hardware acceleration disabled, it seems like Firefox can still use my GPU just fine for WebGL. It's just whatever the use hardware acceleration toggle controls that seems to be the problem.

May be dmabuf related or so.

Component: Widget: Gtk → Graphics

Adding to triage for the team to have a look.

Blocks: gfx-triage
Severity: -- → S3
Component: Graphics → Graphics: WebRender
Priority: -- → P1

If it helps, I have the exact same bug as the original report (Firefox 149 with hardware acceleration on launches but no window shows up and no error messages appear) on Linux/Wayland but with an Nvidia 3070 (using the recent, stable 595.58.03 drivers). So it doesn't seem to be GPU/driver related.

For what it's worth I'm now encountering the same issue in Thunderbird. For the last few weeks it would generally work but randomly freeze, but now it completely hung on startup just like Firefox until I started in safe mode and disabled hardware acceleration.

In Brief - Same On Deb 12 Stable Gnome Wayland

I see the same issue on Debian 12 (Stable), Gnome (Wayland), NVidia Quadro RTX 3000, on single (Laptop) monitor or dual (4k, 144hz/120hz/60hz), full details at the end of my post.

Other Hardware Toggles & Credit To Andrew

I am slowly working my way through the below list of toggles in about:config ... :

  • gfx.webrender.all
  • media.ffmpeg.vaapi.enabled
  • widget.dmabuf.force-enabled
  • media.hardware-video-decoding.force-enabled
  • media.hardware-video-encoding.force-enabled
  • layers.acceleration.force-enabled
  • layers.offmainthreadcomposition.enabled

However I also wanted to thank @aroskuski for the AskU post (mentioned previously and quoted below), otherwise I may have given up on this.

Yeah, I'm the one who made that Ask Ubuntu post. I'm also experiencing this problem on Ubuntu 25.10 with an Geforce 1080 Ti with the Nvidia 580 drivers. I've reproduced the behavior with both the Firefox snap and the tarball directly from Mozilla, so that doesn't seem to make any difference.

Potentially worth mentioning that with hardware acceleration disabled, it seems like Firefox can still use my GPU just fine for WebGL. It's just whatever the use hardware acceleration toggle controls that seems to be the problem.

Full Details

See below:

-Computer-
Processor			: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
Memory				: 32705MB (9859MB used)
Machine Type		: Notebook
Operating System	: Debian GNU/Linux 12 (bookworm)

-Display-
Resolution			: 7680x2160 pixels
OpenGL Renderer		: Quadro RTX 3000/PCIe/SSE2
X11 Vendor			: The X.Org Foundation

-Version-
Kernel				: Linux 6.1.0-43-amd64 (x86_64)
Version				: #1 SMP PREEMPT_DYNAMIC Debian 6.1.162-1 (2026-02-08)
C Library			: GNU C Library / (Debian GLIBC 2.36-9+deb12u13) 2.36
Distribution		: Debian GNU/Linux 12 (bookworm)

Further details

I don't know if this helps or hinders, but I have been seeing FF hang/crash almost routinely without triggering a crash report, ever. It may be related, but I dunno.

Additionally, whilst spiffing up these HW prefs, I also decided to set frame_rate to 144, so ... er ... we'll see what that does?

Apologies, couldn't see a way to edit ... I enabled all of the below and it starts OK, but have not got the check mark in about:preferences because (without fail) that causes it to have the issue.

(In reply to Eliot Cole from comment #7)

I am slowly working my way through the below list of toggles in about:config ... :

  • gfx.webrender.all
  • media.ffmpeg.vaapi.enabled
  • widget.dmabuf.force-enabled
  • media.hardware-video-decoding.force-enabled
  • media.hardware-video-encoding.force-enabled
  • layers.acceleration.force-enabled
  • layers.offmainthreadcomposition.enabled

I'll attempt to reproduce.

Glenn, please adjust S/P as necessary.

Flags: needinfo?(mozilla)

As an additional data point, my x13s laptop (also running Ubuntu 25.10) doesn't seem to have the issue. That machine is also running Wayland, and has a Qualcomm 8cx Gen 3 SoC (which has an aarch64 CPU and an Adreno 690 GPU).

Flags: needinfo?(mozilla)

Just piping in to say that I still have the issue in 149.0.2

Conversely, I have just performed my first test in 149.0.2 (Mozilla Firefox Debian Package 'mozilla-deb' from Mozilla) on Debian 12 (Gnome Wayland) and initial signs are good.

Just piping in to say that I still have the issue in 149.0.2
I will try to come back within a week or so to report further restarts.

So far, though, it looks good on this particular setup.

NB - I am not saying this to discount, or invalidate, Adam's (or anyone else's) experience, though. I do not consider a single success as a finished test of this new version.(In reply to Adam Koszela from comment #12)

PLEASE DELETE ABOVE, badly formatted

Conversely, I have just performed my first test in 149.0.2 (Mozilla Firefox Debian Package 'mozilla-deb' from Mozilla) on Debian 12 (Gnome Wayland) and initial signs are good.

Just piping in to say that I still have the issue in 149.0.2

I will try to come back within a week or so to report further restarts.

So far, though, it looks good on this particular setup.

NB - I am not saying this to discount, or invalidate, Adam's (or anyone else's) experience, though. I do not consider a single success as a finished test of this new version.(In reply to Adam Koszela from comment #12)

Ach, no ... it is unfortunately still occurring with my setup.

I will try to come back within a week or so to report further restarts.

I just experienced it on an important (Firefox) PWA for work running Outlook, which means that I have effectively 'lost access' because PWA for Firefox doesn't have an obvious way to force safe mode.

I'm definitely still experiencing the issue on Firefox 149.0.2, at least on my x86/Nvidia machine.

This might be a profile issue, as I no longer have the issue (same hardware, same kernel, same Nvidia driver, same Firefox version) after formatting and reinstall Linux on my machine (for unrelated reasons).

Nevermind, the problem reappeared after my Linux rig went to sleep, and is now permanent.

Having done some experimentation, I can confirm layers.acceleration.disabled has to be true for Firefox to launch successfully for me. The other settings don't trigger the bug either way.

Do you mind running mozregression to determine what code changes are most likely to blame for the regression? There are instructions for using mozregression at its website https://mozilla.github.io/mozregression/ - roughly this tool will run several Firefox builds and ask you if the problem is present or not in each one, it will pick builds closer and closer to the likely point where it broke and give a report.

Note that mozregression normally uses a fresh profile each time, if you need to login to something to reproduce the issue you may want to use the option for keeping the same profile across runs so you would only have to do so once, I am not sure how to use it for PWA though.

Flags: needinfo?(jan)
Flags: needinfo?(eliot.cole)
Flags: needinfo?(adam.koszela)

For what it's worth, I ran mozregression-gui on my machine, and this was the final change it pointed to:

2026-04-16T18:33:58.492000: INFO : Narrowed integration regression window from [caeb1bb1, 4898d067] (3 builds) to [f9a55c6c, 4898d067] (2 builds) (~1 steps left)
2026-04-16T18:33:58.506000: DEBUG : Starting merge handling...
2026-04-16T18:33:58.506000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=4898d067ee28f052f9d1c57ffde37dc0aad68e33&full=1
2026-04-16T18:33:58.506000: DEBUG : redo: attempt 1/3
2026-04-16T18:33:58.507000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=4898d067ee28f052f9d1c57ffde37dc0aad68e33&full=1',), kwargs: {}, attempt #1
2026-04-16T18:33:58.508000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2026-04-16T18:33:59.035000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=4898d067ee28f052f9d1c57ffde37dc0aad68e33&full=1 HTTP/1.1" 302 0
2026-04-16T18:34:00.080000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=4898d067ee28f052f9d1c57ffde37dc0aad68e33&full=1 HTTP/1.1" 200 None
2026-04-16T18:34:00.118000: DEBUG : Found commit message:
Bug 2001628 [Linux] Make mWindowSurface persistent r=emilio

Right now we create/delete WindowSurface on nsWindow map/unmap event. In this patch we make it persistent
and keep it until nsWindow::Destroy().

Changes:

- Initialize SurfaceProvider at nsWindow::Create() and release at nsWindow::Destroy() so remove ConfigureCompositor/ResumeCompositorImpl() as it's not needed.
- Remove SurfaceProvider::mWindowSurfaceValid as it's always valid (if it's present).
- Start nsWindow VSync source at nsWindow::Create() and stop at nsWindow::Destroy() as we can always paint (even to offscreen / hidden nsWindow).
- Remove nsIWidget::IsMapped() and enable WebRender transaction throttle as we do on other arches - we can always paint now.
- Remove offscreen fallback from GLContextEGL::CreateEGLSurfaceForCompositorWidget() as we always have valid EGLSurface to draw into.
- Set EGLSurface at RenderCompositorEGL::RenderCompositorEGL() instead of fetch at Resume().
- Remove GtkCompositorWidget::SetRenderingSurface() as it's not needed.
- Remove WindowSurfaceProvider mWindowSurface mutex and thread safety hacks.

Differential Revision: https://phabricator.services.mozilla.com/D276964


2026-04-16T18:34:00.120000: DEBUG : Did not find a branch, checking all integration branches
2026-04-16T18:34:00.120000: INFO : The bisection is done.
2026-04-16T18:34:00.121000: INFO : Stopped

Also since I don't think I checked this before, I can also reproduce the issue on the latest nightly build of Firefox.

(In reply to aroskuski from comment #22)

Also since I don't think I checked this before, I can also reproduce the issue on the latest nightly build of Firefox.

By which I mean 151.0a1 (2026-04-16)

Here's the final change mozregression pointed me to (same as @arosskuski):

2026-04-17T09:53:26.284000: DEBUG : Found commit message:
Bug 2001628 [Linux] Make mWindowSurface persistent r=emilio

Right now we create/delete WindowSurface on nsWindow map/unmap event. In this patch we make it persistent
and keep it until nsWindow::Destroy().

Changes:

Initialize SurfaceProvider at nsWindow::Create() and release at nsWindow::Destroy() so remove ConfigureCompositor/ResumeCompositorImpl() as it's not needed.
Remove SurfaceProvider::mWindowSurfaceValid as it's always valid (if it's present).
Start nsWindow VSync source at nsWindow::Create() and stop at nsWindow::Destroy() as we can always paint (even to offscreen / hidden nsWindow).
Remove nsIWidget::IsMapped() and enable WebRender transaction throttle as we do on other arches - we can always paint now.
Remove offscreen fallback from GLContextEGL::CreateEGLSurfaceForCompositorWidget() as we always have valid EGLSurface to draw into.
Set EGLSurface at RenderCompositorEGL::RenderCompositorEGL() instead of fetch at Resume().
Remove GtkCompositorWidget::SetRenderingSurface() as it's not needed.
Remove WindowSurfaceProvider mWindowSurface mutex and thread safety hacks.

Differential Revision: https://phabricator.services.mozilla.com/D276964

2026-04-17T09:53:26.285000: DEBUG : Did not find a branch, checking all integration branches
2026-04-17T09:53:26.285000: INFO : The bisection is done.
2026-04-17T09:53:26.286000: INFO : Stopped

Flags: needinfo?(adam.koszela)

As expected, since it happens on Nightly, I'm still seeing the issue on Firefox 150.

Same here, still present on 150.

stransky, this appears to be a regression from Bug 2001628. Would you please investigate?

Flags: needinfo?(stransky)
Flags: needinfo?(jan)
Flags: needinfo?(eliot.cole)
Keywords: regression
Regressed by: 2001628

Should be reported at NVIDIA - perhaps the drivers doesn't expect we keep the EGLSurface live between hide/show.

Flags: needinfo?(stransky)

I don't think this is an NVIDIA bug, at least not exclusively — I'm running into it on a Thinkpad with an Intel Arc chip, see the support info attachment in the first comment.

(In reply to Jan Larres from comment #29)

I don't think this is an NVIDIA bug, at least not exclusively — I'm running into it on a Thinkpad with an Intel Arc chip, see the support info attachment in the first comment.

I think we're hitting different issues here:

  1. Sway/Intel - I suggest to report at Sway and/or Mesa tracker. I haven't seen any Gnome/Intel/AMD reports about it.
  2. NVIDIA/Gnome - that's NVIDIA one, most probably caused by drivers.

The thing is that we create EGLSurface (may be dmabuf backed) and we keep that between window hide/show. That allows us to continue offscreen rendering even when the parent surface is not visible so we don't have to use sync stop of whole rendering machinery.

Should be noted that when a new profile is created from about:profiles using the 'Create Profile Wizard' it is:

  1. Created with recommended performance settings turned on and that means hardware acceleration
  2. Created as the default for next login
    This means that it ostensibly fails to launch, so, perhaps it may be wise not to have hardware acceleration / recommended performance default to on/true?

Just a thought.

I'll try to run that mozregression thing, [:ahale]

Also, is there no potential that this EGLSurface could be a bit wonky? [:stransky]

Yeah, the way this bug interacts with profile management is pretty bad. There's a test profile that I made related to this bug which has hardware acceleration enabled, and I can't delete it via the profile manager, because the window just closes if I try to do so, seemingly because that process tries to launch Firefox with that profile in a sub process which hangs. Having an unrecoverable hang so early in browser startup seems to interfere with the ability to do profile management in general.

I sent an email to the Nvidia linux-bugs address as suggested (the more public forum seemed to want an excessive amount of personal information before it'd let me post), but even if this does turn out to be purely a driver issue, the way this causes Firefox to behave causes some pretty awkward behavior around profile management, as mentioned in the above comments.

:stransky, since you are the author of the regressor, bug 2001628, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(stransky)

(In reply to Eliot Cole from comment #31)

Also, is there no potential that this EGLSurface could be a bit wonky? [:stransky]

The scenario before Bug 2001628 was:

  1. Disable all rendering (off-main-thread), GL compositing etc.
  2. Create wl_subsurface / wl_surface / EGLSurface
  3. Paint
  4. Window becomes hidden -> block main thread until all painting is done
  5. delete wl_subsurface / wl_surface / EGLSurface

Bug 2001628 comes with:

  1. Create wl_surface / EGLSurface
  2. Do possible rendering (off-main-thread), GL compositing etc.
  3. When window becomes visible, create wl_subsurface and attach wl_surface / EGLSurface to it.
  4. Paint
  5. Window becomes hidden -> delete wl_subsurface, keep wl_surface / EGLSurface live.
  6. Don't block main thread and finish all off-main-thread rendering

So it's possible that particular wayland compositor/gfx driver has a problem with offscreen rendering to EGLSurface.
So far I've seen reports from Sway (any kind of drivers) and NVIDIA (different kind of Wayland compositors).

Note that this behavior is correct from Wayland protocol and/or GL perspective. We have valid wl_surface / EGLSurface we can paint to.

Flags: needinfo?(stransky)

I've just tested again on my system (defined here) using Nightly (version 152.0a1 (2026-04-26) (64-bit)), from the mozilla-deb repo, and the issue pervades.

I have still not tried the regression thingumy.

Purely as an aside, if one is running Debian 12 (which, as a 'stable' OS, may be required by work), there is no option to update the drivers beyond their current state and continue to have useful functionality from them.

Least not an obvious, easy, one. Plus, if one does one will be tutted at for 'franken-debian' ... which ... well ... it's a bit funny, but whatever. :smirk:

In case it matters, I'm on NVIDIA/KDE/Wayland (not GNOME).

I just did a test on my system and discovered that Firefox also hangs under Gnome, not just Sway, so it seems to be Mesa/driver issue instead of being Sway-specific.

Still a problem with the new 595.71.05 Linux NVIDIA drivers and Firefox 150.0.1.

I've raised a Mesa bug here: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15387

Taking this out of triage, assigning to :stransky both as the author of the regressor, and the person who knows most about this code.

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

Will be posting under a new ID shortly

Just wanted to say that I cannot start the profile manager at all, despite this (my default profile) running without hardware acceleration enabled.

Jan, I forget, is 'Mesa' the standard (nouveau) drivers, or the proprietary one?
(In reply to Jan Larres from comment #40)

I've raised a Mesa bug here: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15387

I'm not sure that I've been clear on that, myself. I am using the proprietary NVidia drivers on a luks encrypted drive OS of Debian 12 ... obviously that means that they cannot be updated/changed and at the same time leave me in a simple position to regress said change regarding this all. Am therefore somewhat reliant on things just ... 'turning out for the best' here ... heh.

(In reply to Eliot Cole from comment #42)

Just wanted to say that I cannot start the profile manager at all, despite this (my default profile) running without hardware acceleration enabled.

Same for me, I had to use the CLI to test different profiles.

Jan, I forget, is 'Mesa' the standard (nouveau) drivers, or the proprietary one?

Neither in my case since I use an Intel chip, whose drivers are part of Mesa. The proprietary Nvidia drivers are completely separate from Mesa.

It's been more than a month since I sent an email to Nvidia's bug email about this, and I've yet to receive a response. The driver updates I've gotten since then also don't seem to have helped (currently on 580.159.03).

Same here. Still an issue for me on CachyOS with an Nvidia 3070, Firefox 151.0.2, and Nvidia's 610.43.02 Linux driver.

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

Attachment

General

Creator:
Created:
Updated:
Size: