2026116 - [KDE/NVIDIA] No visible window since 149.0

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect)

Description

[insuna]

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

Steps to reproduce:

Updated to Firefox 149, attempted to start Firefox.

Actual results:

No window opened, but a bunch of firefox processes appear in htop and stay there. Attaching to them with strace shows nothing of use, they all seem to wait on some FUTEX or read.

Occasionally the "troubleshooting mode" popup appears when attempting to start and in this mode firefox seems to work normally, except ofc that all extensions are missing. Manually disabling all extensions does not fix the issue.

Note that I am writing this report on firefox after downgrading it back to 148.

There are no logs indicating any issues in systemd.

The system I'm on is Linux 6.18.12 with Nvidia drivers 575.64.05 with KDE desktop environment using Wayland

Expected results:

Firefox window should open and be usable normally.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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 2

[insuna]

For testing I just downloaded the latest firefox 149.0 release from the firefox website and started it with strace and this is where it gets stuck:

futex(0x76a06339a954, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY

Comment 3

[insuna]

Attachment: gdb excerpt

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Can you please try nightly binaries with clean profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

You can also use mozregression tool with your recent/broken profile:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
(use the --profile / --profile-persistence params)

Comment 6

[insuna]

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

Can you please try nightly binaries with clean profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Hi Martin,

I have attempted to start firefox nightly

./firefox --version
Mozilla Firefox 151.0a1

with a blank profile. It spawns a bunch of processes I can see in htop but it does not spawn any window. The profile it creates is also wildly incomplete:

╰─ ll
total 940K
drwxr-xr-x   10 username username 4.0K 26. Mär 14:28 .
drwx--x--x+ 168 username username  16K 26. Mär 14:25 ..
-rw-r--r--    1 username username  96K 26. Mär 14:27 bounce-tracking-protection.sqlite
drwx------    4 username username 4.0K 26. Mär 14:27 cache2
-rw-------    1 username username 224K 26. Mär 14:27 cert9.db
-rw-------    1 username username  273 26. Mär 14:27 compatibility.ini
-rw-r--r--    1 username username  96K 26. Mär 14:27 cookies.sqlite
drwx------    3 username username 4.0K 26. Mär 14:27 crashes
drwxr-xr-x    2 username username 4.0K 26. Mär 14:27 extension-store
drwxr-xr-x    2 username username 4.0K 26. Mär 14:27 extension-store-permissions
-rw-------    1 username username 288K 26. Mär 14:27 key4.db
drwx------    2 username username 4.0K 26. Mär 14:27 minidumps
-rw-r--r--    1 username username    0 26. Mär 14:27 .parentlock
-rw-r--r--    1 username username 160K 26. Mär 14:27 permissions.sqlite
-rw-------    1 username username  452 26. Mär 14:27 pkcs11.txt
drwxr-xr-x    2 username username 4.0K 26. Mär 14:27 security_state
-rw-r--r--    1 username username   53 26. Mär 14:27 sessionCheckpoints.json
-rw-r--r--    1 username username  286 26. Mär 14:27 SiteSecurityServiceState.bin
drwxr-xr-x    2 username username 4.0K 26. Mär 14:27 startupCache
-rw-r--r--    1 username username    0 26. Mär 14:27 .startup-incomplete
drwxr-xr-x    5 username username 4.0K 26. Mär 14:27 storage
-rw-r--r--    1 username username 4.0K 26. Mär 14:27 storage.sqlite
-rw-r--r--    1 username username   50 26. Mär 14:27 times.json

There is no terminal output. I closed the process again with sigterm through htop.

As for my recent/broken profiles: I've restored them from backups because firefox somewhat regularly corrupts my profiles. I do not keep the corrupted version. That is to be expected however, as firefox crashes at least 5 times per day for me, whenever I open or close a sub-window (like from an extension, or picture-in-picture).

Comment 7

[insuna]

using MOZ_ENABLE_WAYLAND=0 I can start the latest version of nightly without issues.

Thank you for the time you're using to help me with this. It is highly appreciated!

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Please try the mozregression to find broken commit.
Also please attach about:support page from the working browser.
Thanks.

Comment 9

[insuna]

The result of Mozregession is as follows. Attaching a screenshot, too.

2026-04-01T18:47:50.706000: 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-01T18:47:50.706000: DEBUG : Did not find a branch, checking all integration branches
2026-04-01T18:47:50.706000: INFO : The bisection is done.
2026-04-01T18:47:50.707000: INFO : Stopped

Comment 10

[insuna]

Attachment: image.png

screenshot from mozregression run

Comment 11

[insuna]

Attachment: about_support.txt

about:support from working version

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Ah I see, thanks. That makes sense. Looks like a bug in NVIDIA drivers and/or in KDE. Which KDE version do you run? Can you try Firefox in safe mode?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Run_in_safe_mode
Thanks.

Comment 13

[insuna]

Hi Martin, thank you for your time.
Safe mode did not work. I updated my Nvidia drivers today to 595.58.03 and I still experience the same issue.
KDE version is:

• KDE Plasma: 6.6.3
• KDE Frameworks: 6.24.0
• QT Version: 6.10.2

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Can you try to disable HW acceleration?
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Force_disable_hardware_acceleration
(perhaps with MOZ_ENABLE_WAYLAND=0 in X11 and then try Wayland).
Thanks.

Comment 15

[insuna]

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

Can you try to disable HW acceleration?
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Force_disable_hardware_acceleration
(perhaps with MOZ_ENABLE_WAYLAND=0 in X11 and then try Wayland).
Thanks.

Hi Martin,

disabling HW acceleration has allowed Firefox 149 to start with MOZ_ENABLE_WAYLAND=1

hope this helps.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

Okay, Thanks. I'd report that NVIDIA then. It's related to GL code.

Comment 17

[insuna]

So the best path forward is to fix my Firefox version to 148 or switch to Chromium? Because Nvidia sure as night will never fix this. I tried using Firefox with HW acceleration disabled and it was atrocious and ever since then keeps bugging out, even with it enabled again now. (Scrolling through a page creates artifacts and sometimes just breaks rendering completely; tho it can be unstuck by opening a new tab, minimizing the window, maximizing the window, minimizing it again and finally maximizing it again)

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Can you try different compositor like Gnome? May be also KDE related bug.
Thanks.