[Sway][NVIDIA] Freeze of UI in Linux Wayland when opening password save popup
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: max, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files)
screenshot-04.03.2026-10.47.00.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0
Steps to reproduce:
After updating to Firefox 149-beta3 in Wayland (sway), I have a problem that the complete UI freezes and I need to kill Firefox and restart it again.
This happens after a login, and I think this happens when Firefox tries to open the small popup to save the password, as on the left where the small key symbol should be shown, only a narrow, empty element is shown.
This also happened initially when I wanted to open the Devtools, however this could be resolved by removing the xulstore.json.
After that I could open the Devtools again. Therefore I was thinking that it is maybe related to the following issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1998188 However now Firefox does not crash.
For now I downgraded to Firefox 148 stable where this issue does not occur (with the same profile).
Actual results:
UI freeze.
Expected results:
No UI freeze.
|
||
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 months ago
|
||
Hello max, thanks for the report.
Could you record a profile using https://profiler.firefox.com/ and share it here so we can better understand what's going on? Thanks
Hey Nicolas, just to make sure, I should start recording a profile and then trigger the bug?
|
|
||
Comment 4•2 months ago
|
||
(In reply to max from comment #3)
Hey Nicolas, just to make sure, I should start recording a profile and then trigger the bug?
yes, then hopefully it doesn't freezes so hard that you can't stop the recording
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #4)
(In reply to max from comment #3)
Hey Nicolas, just to make sure, I should start recording a profile and then trigger the bug?
yes, then hopefully it doesn't freezes so hard that you can't stop the recording
Okay, I will suspect it freezes so hard, that I cannot stop recording, as I could not even scroll on webpages anymore, and also other windows did not render and any keypresses did not have any effects, after the freeze.
I will do it after my workday, as I need to upgrade again to the beta version.
I tried to run the profiler, but as the complete browser freezes, it also did not open the resulting profiler output.
I then ran Firefox with the flags, I used for the last bug: MOZ_LOG="Widget:5,WidgetPopup:5", and attached the output. After the
[Parent 16121: Main Thread]: D/Widget [7fd28912c600]: redirect painting to OMTC rendering...
The browser was not reacting anymore.
I use a Nvidia GPU, with the official Nvidia driver, and a scaling of 1.5.
I also attached the resulting broken state of the password manager, however I triggered the freeze by opening the devtools.
|
||
Comment 10•2 months ago
|
||
Henrik, do you know if we can capture a profile even if Firefox crashes ?
|
||
Comment 11•2 months ago
|
||
I don't think so, and that even not with startup and shutdown profiling. AFAIK we only save on successful quit.
Maybe it might be better to use mozregression to actually find the regression range.
|
|
||
Comment 12•2 months ago
|
||
Good idea, Max can you try to find a regression range with https://mozilla.github.io/mozregression ?
|
Reporter | |
Comment 13•2 months ago
|
||
I bisected the issue and found the following:
2026-03-04T16:30:05.094000: 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-03-04T16:30:05.096000: DEBUG : Did not find a branch, checking all integration branches
2026-03-04T16:30:05.097000: INFO : The bisection is done.
|
|
||
Comment 14•2 months ago
|
||
Thanks! Emilio do you think this could be a regression from Bug 2001628 ?
|
||
Comment 15•2 months ago
|
||
Seems believable... Seems we could be deadlocking?
|
|
||
Comment 16•2 months ago
|
||
A backtrace would be useful, any chance that on the frozen firefox you could do:
gdb -p <firefox-pid> # Make sure to choose the parent pid (the one that doesn't have contentProc as a flag)
(gdb) thread apply all bt
And paste the output here?
|
|
Reporter | |
Comment 17•2 months ago
|
||
|
|
Reporter | |
Comment 18•2 months ago
|
||
I added the backtace, not that in order to make it simpler, I closed all my other tabs and windows, then the bug could not be reproduced by opening the dev tools anymore, however opening the password popup triggered the freeze.
|
|
||
Comment 19•2 months ago
|
||
Seems the main issue is:
#0 0x00007fa4042f704d in ioctl () from /usr/lib/libc.so.6
#1 0x00007fa3da233671 in drmIoctl () from /usr/lib/libdrm.so.2
#2 0x00007fa3da23818b in drmSyncobjTimelineWait () from /usr/lib/libdrm.so.2
#3 0x00007fa3d84b4b20 in ?? () from /usr/lib/libnvidia-egl-wayland.so.1
#4 0x00007fa3cce6ed06 in ?? () from /usr/lib/libEGL_nvidia.so.0
#5 0x00007fa3cce0d71f in ?? () from /usr/lib/libEGL_nvidia.so.0
#6 0x00007fa3f15a53b8 in mozilla::gl::GLContextEGL::SwapBuffers() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#7 0x00007fa3f15a40ae in mozilla::wr::RenderCompositorEGL::EndFrame(nsTArray<mozilla::wr::Box2D<int, mozilla::wr::DevicePixel> > const&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#8 0x00007fa3f15a2efc in mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId, mozilla::layers::BaseTransactionId<mozilla::VsyncIdType> const&, mozilla::TimeStamp const&, mozilla::wr::FrameReadyParams const&, mozilla::Maybe<mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> > const&, mozilla::Maybe<mozilla::wr::ImageFormat> const&, mozilla::Maybe<mozilla::Range<unsigned char> > const&, mozilla::wr::RendererStats*, bool*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#9 0x00007fa3f19aaec2 in mozilla::wr::RenderThread::HandleFrameOneDocInner(mozilla::wr::WrWindowId, mozilla::wr::FrameReadyParams const&, mozilla::Maybe<mozilla::wr::FramePublishId>) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#10 0x00007fa3f19aa8ae in mozilla::wr::RenderThread::HandleWrNotifierEvents(mozilla::wr::WrWindowId) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#11 0x00007fa3f19aa6f3 in mozilla::detail::RunnableMethodImpl<mozilla::storage::AsyncExecuteStatements*, nsresult (mozilla::storage::AsyncExecuteStatements::*)(mozilla::storage::ResultSet*), true, (mozilla::RunnableKind)0, RefPtr<mozilla::storage::ResultSet> >::Run() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#12 0x00007fa3f18edfa9 in NS_ProcessNextEvent(nsIThread*, bool) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#13 0x00007fa3f18ebfdd in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#14 0x00007fa3f2e1d04a in nsThread::ThreadFunc(void*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#15 0x00007fa4041c36a5 in _pt_root () from /tmp/tmppvjtvd6w/firefox/libnspr4.so
#16 0x000056249df1f849 in set_alt_signal_stack_and_start(PthreadCreateParams*) ()
#17 0x00007fa40427797a in ?? () from /usr/lib/libc.so.6
#18 0x00007fa4042fb2bc in ?? () from /usr/lib/libc.so.6
So hung up in the graphics driver / kernel?
Then the main thread tries to communicate with the renderer in:
Thread 1 (Thread 0x7fa40469b7c0 (LWP 67282) "firefox-bin"):
#0 0x00007fa40427ff32 in ?? () from /usr/lib/libc.so.6
#1 0x00007fa40427439c in ?? () from /usr/lib/libc.so.6
#2 0x00007fa40427468c in ?? () from /usr/lib/libc.so.6
#3 0x00007fa404276e5e in pthread_cond_wait () from /usr/lib/libc.so.6
#4 0x000056249df808d5 in mozilla::detail::ConditionVariableImpl::wait_for(mozilla::detail::MutexImpl&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) ()
#5 0x00007fa3f2ed70dc in mozilla::ipc::IProtocol::ChannelSend(std::unique_ptr<IPC::Message, std::default_delete<IPC::Message> >, std::unique_ptr<IPC::Message, std::default_delete<IPC::Message> >*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#6 0x00007fa3f208422f in mozilla::layers::PCompositorBridgeChild::SendFlushRendering(mozilla::wr::RenderReasons const&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#7 0x00007fa3f20840b8 in mozilla::layers::WebRenderLayerManager::FlushRendering(mozilla::wr::RenderReasons) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#8 0x00007fa3f650a438 in nsMenuPopupFrame::PaintWindow(nsIWidget*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#9 0x00007fa3f3887ac9 in nsWindow::OnExposeEvent(_cairo*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#10 0x00007fa3f3887792 in expose_event_cb(_GtkWidget*, _cairo*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#11 0x00007fa3fa0982f7 in ?? () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#12 0x00007fa3fa34f548 in ?? () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#13 0x00007fa3fb35f6bd in ?? () from /opt/mozregression-gui/_internal/libgobject-2.0.so.0
#14 0x00007fa3fb35f7c1 in g_signal_emit_valist () from /opt/mozregression-gui/_internal/libgobject-2.0.so.0
#15 0x00007fa3fb35f883 in g_signal_emit () from /opt/mozregression-gui/_internal/libgobject-2.0.so.0
#16 0x00007fa3fa361fa1 in ?? () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#17 0x00007fa3fa11ae02 in gtk_container_propagate_draw () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#18 0x00007fa3fa11af14 in ?? () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#19 0x00007fa3fa361e94 in ?? () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#20 0x00007fa3fa365f3f in ?? () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#21 0x00007fa3fa204408 in gtk_main_do_event () from /opt/mozregression-gui/_internal/libgtk-3.so.0
#22 0x00007fa3f9f3f407 in ?? () from /opt/mozregression-gui/_internal/libgdk-3.so.0
#23 0x00007fa3f9f51929 in ?? () from /opt/mozregression-gui/_internal/libgdk-3.so.0
#24 0x00007fa3f9f55ff5 in ?? () from /opt/mozregression-gui/_internal/libgdk-3.so.0
#25 0x00007fa3f9f56201 in ?? () from /opt/mozregression-gui/_internal/libgdk-3.so.0
#26 0x00007fa3fb35f6bd in ?? () from /opt/mozregression-gui/_internal/libgobject-2.0.so.0
#27 0x00007fa3fb35f7c1 in g_signal_emit_valist () from /opt/mozregression-gui/_internal/libgobject-2.0.so.0
#28 0x00007fa3fb35f883 in g_signal_emit () from /opt/mozregression-gui/_internal/libgobject-2.0.so.0
#29 0x00007fa3f9f4cb58 in ?? () from /opt/mozregression-gui/_internal/libgdk-3.so.0
#30 0x00007fa3f9f38c6d in ?? () from /opt/mozregression-gui/_internal/libgdk-3.so.0
#31 0x00007fa3f9e1a4a2 in ?? () from /opt/mozregression-gui/_internal/libglib-2.0.so.0
#32 0x00007fa3f9e1940e in ?? () from /opt/mozregression-gui/_internal/libglib-2.0.so.0
#33 0x00007fa3f9e78767 in ?? () from /opt/mozregression-gui/_internal/libglib-2.0.so.0
#34 0x00007fa3f9e189d3 in g_main_context_iteration () from /opt/mozregression-gui/_internal/libglib-2.0.so.0
#35 0x00007fa3f18ecaba in NS_ProcessNextEvent(nsIThread*, bool) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#36 0x00007fa3f18eaec7 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#37 0x00007fa3f2e22a7e in nsBaseAppShell::Run() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#38 0x00007fa3f2e228be in nsAppShell::Run() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#39 0x00007fa3f33208a5 in nsAppStartup::Run() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#40 0x00007fa3f3746f00 in XREMain::XRE_mainRun() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#41 0x00007fa3f3744db6 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#42 0x00007fa3f3743abd in XRE_main(int, char**, mozilla::BootstrapConfig const&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#43 0x000056249df2e23c in main ()
And the compositor is waiting for:
Thread 81 (Thread 0x7fa3d85416c0 (LWP 67408) "Compositor"):
#0 0x00007fa40427ff32 in ?? () from /usr/lib/libc.so.6
#1 0x00007fa40427439c in ?? () from /usr/lib/libc.so.6
#2 0x00007fa40427468c in ?? () from /usr/lib/libc.so.6
#3 0x00007fa404276e5e in pthread_cond_wait () from /usr/lib/libc.so.6
#4 0x00007fa4041d736e in PR_Wait () from /tmp/tmppvjtvd6w/firefox/libnspr4.so
#5 0x00007fa3f337570a in mozilla::layers::SynchronousTask::Wait(unsigned int) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#6 0x00007fa3f290f331 in mozilla::wr::WebRenderAPI::WaitUntilPresentationFlushed() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#7 0x00007fa3f37b3e0c in mozilla::layers::CompositorBridgeParent::RecvFlushRendering(mozilla::wr::RenderReasons const&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#8 0x00007fa3f2e05024 in mozilla::layers::PCompositorBridgeParent::OnMessageReceived(IPC::Message const&, std::unique_ptr<IPC::Message, std::default_delete<IPC::Message> >&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#9 0x00007fa3f2e04d55 in mozilla::layers::PCompositorManagerParent::OnMessageReceived(IPC::Message const&, std::unique_ptr<IPC::Message, std::default_delete<IPC::Message> >&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#10 0x00007fa3f2e04bcb in mozilla::ipc::MessageChannel::DispatchSyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&, std::unique_ptr<IPC::Message, std::default_delete<IPC::Message> >&) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#11 0x00007fa3f18fbcfe in mozilla::ipc::MessageChannel::MessageTask::Run() () from /tmp/tmppvjtvd6w/firefox/libxul.so
#12 0x00007fa3f18ee566 in NS_ProcessNextEvent(nsIThread*, bool) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#13 0x00007fa3f18ebfdd in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#14 0x00007fa3f2e1d04a in nsThread::ThreadFunc(void*) () from /tmp/tmppvjtvd6w/firefox/libxul.so
#15 0x00007fa4041c36a5 in _pt_root () from /tmp/tmppvjtvd6w/firefox/libnspr4.so
#16 0x000056249df1f849 in set_alt_signal_stack_and_start(PthreadCreateParams*) ()
#17 0x00007fa40427797a in ?? () from /usr/lib/libc.so.6
#18 0x00007fa4042fb2bc in ?? () from /usr/lib/libc.so.6
|
|
Reporter | |
Comment 20•2 months ago
|
||
Maybe as additional information, I am using the kernel 6.18.13-arch1-1, wlroots0.19 0.19.2-2 and nvidia-580xx-dkms 580.126.18-2 and have a GeForce GTX 1060:
01:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)
Furthermore on my laptop with a more recent AMD GPU, but the rest should be the same, problem does not occur.
|
||
Comment 21•2 months ago
|
||
Can you try different compositor like KDE/GNOME?
You can also try to disable HW acceleration:
https://support.mozilla.org/gl/questions/1075185
Thanks.
|
|
Reporter | |
Comment 22•2 months ago
|
||
Sorry, I was not in the office, where the problem occurs.
So disabling the HW acceleration seems to fix the issue. I currently only have sway installed, but I will look into installing another compositor and report back.
|
|
Reporter | |
Comment 23•1 month ago
|
||
So I checked, the problem does not occur when the hardware acceleration is disabled (but then the UI feels very laggy) and the problem also does not occur in Gnome.
|
||
Updated•1 month ago
|
|
|
Reporter | |
Comment 24•1 month ago
|
||
So, just to make sure that I understand it correctly, judging from the severity and priority, there is no interest in fixing this bug on Firefox side?
Or do you think it is a bug in other parts, and I should report it elsewhere?
|
|
||
Comment 25•1 month ago
|
||
(In reply to max from comment #24)
So, just to make sure that I understand it correctly, judging from the severity and priority, there is no interest in fixing this bug on Firefox side?
Or do you think it is a bug in other parts, and I should report it elsewhere?
Yes, it looks like a bug in NVDIA drivers so please report there. It hangs in closed source drivers so we have no idea what's going on there.
|
||
Comment 26•1 month ago
|
||
Hello max,
I'm have the same problem with almost the same setup as you but with more up-to-date packages.
Did you end up reporting the issue to NVIDIA or somewhere else? If so, could you provide a link for tracking?
Thanks!
|
|
Reporter | |
Comment 27•1 month ago
|
||
Hey, no unfortunately I did not find time, to lookup where and how to report the Nvidia bug. I just downgraded to Firefox 148 for now, as I currently have no time to deal with it in more detail.
|
|
||
Comment 28•1 month ago
|
||
Disabling explicit sync by setting __NV_DISABLE_EXPLICIT_SYNC=1 as suggested here seems to fix the problem.
|
|
Reporter | |
Comment 29•1 month ago
|
||
That is correct, it also fixes the issue for me. Thank you for letting me know and adding the information here in this bug report.
|
||
Comment 30•27 days ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #25)
Yes, it looks like a bug in NVDIA drivers so please report there. It hangs in closed source drivers so we have no idea what's going on there.
I was about to mark this bug blocked-thirdparty but given the regression from bug 2001628 I wonder if we should do anything here. Is this bad as in "hits any user with proprietary nividia drivers" ? Should we disable something for known bad configurations ?
|
|
||
Comment 31•25 days ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #30)
(In reply to Martin Stránský [:stransky] (ni? me) from comment #25)
Yes, it looks like a bug in NVDIA drivers so please report there. It hangs in closed source drivers so we have no idea what's going on there.
I was about to mark this bug
blocked-thirdpartybut given the regression from bug 2001628 I wonder if we should do anything here. Is this bad as in "hits any user with proprietary nividia drivers" ? Should we disable something for known bad configurations ?
May be related to Bug 2027480.
|
|
||
Comment 32•25 days ago
•
|
||
I think we're hitting different issues here:
- Sway/Intel - I suggest to report at Sway and/or Mesa tracker. I haven't seen any Gnome/Intel/AMD reports about it.
- 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.
Description
•