Closed Bug 1921999 Opened 11 months ago Closed 5 months ago

Firefox UI episodically hangs for short periods with Fedora

Categories

(Core :: Widget: Gtk, defect, P2)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 130
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1951249

People

(Reporter: bradley.g.smith, Unassigned)

References

Details

Attachments

(4 files)

about:support as a text file
101.11 KB, text/plain
Details
aboutsupport_export.txt
45.52 KB, text/plain
Details
about_support.txt
55.83 KB, text/plain
Details
zipped Widget:5 log file
226.02 KB, application/zip
Details

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

Steps to reproduce:

Using firefox as primary web browser.
View any web site
Experience periodic Firefox UI hangs or freezes.

Reported at https://bugzilla.redhat.com/show_bug.cgi?id=2315475. And directed to file a bug with mozilla under Core / Widget Gtk component.

Actual results:

The firefox user interface freezes for a few seconds. Will not scroll, respond to keyboard or mouse events for a few seconds (3 to 6 seconds). After then UI seems to respond normally until next freeze.

Expected results:

Normal smooth UI

Fedora support suggests that this may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1921999.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core
Component: DOM: UI Events & Focus Handling → Widget: Gtk

Please attach about:support page from your recent (broken) browser.

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

Flags: needinfo?(bradley.g.smith)
Priority: -- → P2

As requested: about:support as plain text.

about:support attach as plain text file. Please let me know if another format is more suitable. I will let you know about the effect of a clean profile. I certainly have been migrating this profile from each edition of Fedora for a long, long time.

Flags: needinfo?(bradley.g.smith)

I have recently started noticing random hangs, just like the ones described here, in Firefox Nightly. It started happening during the three first weeks of January. I am curious if it is perhaps related to drag-n-drop-issues, just like in https://bugzilla.mozilla.org/show_bug.cgi?id=1917854, as the freezes are identical. The whole UI freezes and nothing is reacting to inputs, but inputs are processed in bulk (and in order) as soon as the UI unfreezes, and the freezes seem to come from drag-n-drops happening, although it's difficult to be sure as the new freezes I've noticed are not as simple to reproduce as the ones I had before it was fixed in bug 1917854.

Perhaps I'm wrong, and they are not related, but I just thought it could be helpful in finding and eliminating the problem. Thanks!

I realized today that I do not recall experiencing these hangs for the last several days. I am not sure what change on the Fedora side that might be related to this bug going away (fingers crossed!). I did, however, change the graphics card on my Fedora workstation from an Nvidia GTX 1060 to an Nvidia RTX 3060. The change was done a few days ago. The same drivers (from rpmfusion) are in place but the replacement graphics card is faster and has more memory (12 GB vs 3 GB). Related? I have no idea but I hopefully this problem is no longer an issue for me. It was certainly annoying.

I have same problem.

I using Arch Linux with wayland.

My laptop is ThinkPad X13 Gen1 (AMD Ryzen 7 4750U),
So probably it doesn't caused by NVIDIA Graphics.

Please try to run on terminal with MOZ_LOG="WidgetDrag:5" env variable. When the freeze happens, can you switch to terminal and copy the log lines here? I expect to see something like 'doing iteration, mWaitingForDragDataRequests' there which means we're waiting to get the D&D data.

To eliminate gfx factor you can disable HW acceleration:
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Force_disable_hardware_acceleration

Thanks.

Flags: needinfo?(bradley.g.smith)

It may be also related to Bug 1943789 which was fixed recently.

Now I have change config to gfx.webrender.software to true,
so It is seems like something like around GPU rendering?

I have been using firefox configured as request but found only one log entry:

[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt

I did not see any hangs.

I should also note that, as I wrote in comment 7 above, I have not experienced any hangs for a while. I did change the graphics card on this machine which might possibly be related (unlikely) but expect that something in Fedora and/or Firefox recently resolved the issue for me.

Flags: needinfo?(bradley.g.smith)

Of course immediately after I posted the comment above:

❯ firefox
[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] nsDragSession::nsDragSession()
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] nsDragSession::InvokeDragSession
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] nsDragSession::InvokeDragSessionImpl
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00]   numDragItems = 1
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/x-moz-url
[Parent 1748342: Main Thread]: D/WidgetDrag adding target _NETSCAPE_URL
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/x-moz-url-data
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/x-moz-url-desc
[Parent 1748342: Main Thread]: D/WidgetDrag adding target application/x-moz-custom-clipdata
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/_moz_htmlcontext
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/_moz_htmlinfo
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/html
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/plain
[Parent 1748342: Main Thread]: D/WidgetDrag adding target text/plain;charset=utf-8
[Parent 1748342: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (7f57a4fd69d0)
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] nsDragSession::SourceBeginDrag(7f57a4fd69d0)
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] nsDragSession::SetDragIcon(7f57a4fd69d0)
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00]   We have a surface
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00]   GdkDragContext [7f57a4fd69d0] nsWindow [7f574a385900]
[Parent 1748342: Main Thread]: D/WidgetDrag invisibleSourceDragFailed(7f57a4fd69d0) GTK_DRAG_RESULT_NO_TARGET
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] SourceEndDragSession(7f57a4fd69d0) result GTK_DRAG_RESULT_NO_TARGET
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00]   guess drag end point 68 577
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00]   drop action is none
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] nsDragSession::Schedule(0) task eDragTaskSourceEnd window 0
[Parent 1748342: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(7f57a4fd69d0)
[Parent 1748342: Main Thread]: D/WidgetDrag [D 0][7f579a355e00] SourceEndDragSession(7f57a4fd69d0) result GTK_DRAG_RESULT_SUCCESS
[Parent 1748342: Main Thread]: D/WidgetDrag mShell::drag_motion
[Parent 1748342: Main Thread]: D/WidgetDrag WindowDragMotionHandler target nsWindow [7f574a385900]
[Parent 1748342: Main Thread]: D/WidgetDrag WindowDropPosition [41, 516]
[Parent 1748342: Main Thread]: D/WidgetDrag [D 1][7f579a355e00] nsDragSession::Schedule(7f57b5965450) task eDragTaskMotion window 7f574a385900
[Parent 1748342: Main Thread]: D/WidgetDrag [D 1][7f579a355e00]    task does not fit recent task eDragTaskSourceEnd, quit!
[Parent 1748342: Main Thread]: D/WidgetDrag mShell::drag_motion, returns 0
[Parent 1748342: Main Thread]: D/WidgetDrag [D 1][7f579a355e00] nsDragSession::RunScheduledTask() task eDragTaskSourceEnd mTargetWindow 0 mPendingWindow 0
[Parent 1748342: Main Thread]: D/WidgetDrag [D 1][7f579a355e00]   quit, selected task eDragTaskSourceEnd
[Parent 1748342: Main Thread]: D/WidgetDrag [D 1][7f579a355e00] nsDragSession::EndDragSessionImpl(0) 1

(In reply to KiYugadgeter from comment #11)

Now I have change config to gfx.webrender.software to true,
so It is seems like something like around GPU rendering?

Yes, change config to gfx.webrender.software to true disables HW acceleration so it workarounds possible bugs in HW drivers. Try to flip back to gfx.webrender.software to false (which enabled HW acceleration) if you don't see any issues.

Here's my about:support file from this morning.

I've cleared my cache and my places database as per, https://support.mozilla.org/en-US/kb/firefox-hangs-or-not-responding.

I'll try Firefox as a flatpak next.

Here is my attached about:support file.

Just now this problem happened even gfx.webrender.software to true.
Also MOZ_LOG="WidgetDrag:5, is enabled, but nothing to output to log file.

Attached file about_support.txt —

This is my about support file

(In reply to KiYugadgeter from comment #17)

Just now this problem happened even gfx.webrender.software to true.
Also MOZ_LOG="WidgetDrag:5, is enabled, but nothing to output to log file.

I've had the same results.

Can you run on terminal with MOZ_LOG="Widget:5" and if you see the freeze, please switch to terminal and check if you get events logging (mouse/keyboard) or any other log update.
Thanks.

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

Can you run on terminal with MOZ_LOG="Widget:5" and if you see the freeze, please switch to terminal and check if you get events logging (mouse/keyboard) or any other log update.
Thanks.

Yes, how exactly do I set it to log while running firefox?

I have similar stalls, around 2 weeks on Fedora 41, very annoying (my "solution" is to activate Overview mode by swiping mouse to left up angle to unfreeze (or pressing Win button), then after another stall that happen maybe in 30 sec again, and again and again...).
I do MOZ_LOG="Widget:5" firefox as in last note, it instantly flood terminal with lines with Parent window, Button pressed, etc, very smooth and fast (I have AMD Ryzen 9 5950X Radeon 580 GPU). I rearrange windows side by side, terminal at left and firefox at right, then wait to stall kick in. When it freeze, I move mouse around text and over some web active elements. Address line at top somewhat react, at least it change cursor. But, no other visoble changes on right firefox window, ir appear completely hang and frozen. But same time, left terminal live and kicking as nothing bad happens, all that messages keep flooding as I move mouse, Pressing events, as mouse pass different windows, as nothing bad happen. It is looks like firefox actually work behind, only it stop update screen. For example, if I move mouse over some active element liike drop list, and "blindly" click and select something, and then do my usual "unfreeze" action as activate Overview, then firefox show correct drop list popup and everything ok.

Personally, I feel it is maybe something with graph engine with caching that suddenly forget to mark damaged portion of screen to update. But as Firefox is only program that suffer that freezes, maybe it is some firefox internal shenanigans, not system.

Got it! At the terminal firefox --MOZ_LOG="Widget:5"

This is a zipped Widget:5 log file when freeze happen.

Raw text file is bigger than limitation of upload file size.

Flags: needinfo?(stransky)

(In reply to kartochka378 from comment #22)

I have similar stalls, around 2 weeks on Fedora 41, very annoying (my "solution" is to activate Overview mode by swiping mouse to left up angle to unfreeze (or pressing Win button), then after another stall that happen maybe in 30 sec again, and again and again...).
I do MOZ_LOG="Widget:5" firefox as in last note, it instantly flood terminal with lines with Parent window, Button pressed, etc, very smooth and fast (I have AMD Ryzen 9 5950X Radeon 580 GPU). I rearrange windows side by side, terminal at left and firefox at right, then wait to stall kick in. When it freeze, I move mouse around text and over some web active elements. Address line at top somewhat react, at least it change cursor. But, no other visoble changes on right firefox window, ir appear completely hang and frozen. But same time, left terminal live and kicking as nothing bad happens, all that messages keep flooding as I move mouse, Pressing events, as mouse pass different windows, as nothing bad happen. It is looks like firefox actually work behind, only it stop update screen. For example, if I move mouse over some active element liike drop list, and "blindly" click and select something, and then do my usual "unfreeze" action as activate Overview, then firefox show correct drop list popup and everything ok.

Personally, I feel it is maybe something with graph engine with caching that suddenly forget to mark damaged portion of screen to update. But as Firefox is only program that suffer that freezes, maybe it is some firefox internal shenanigans, not system.

Maybe false alarm, I disabled cough"youtube accelerator" plugin that have rights to full access to everything and start glitching (other issues, not related to this bug) around month and half ago, and zero stalls since disabling so far (before, Firefox stall after every 20-30 seconds).

Can you try to set widget.wayland.vsync.enabled to false at about:config and restart browser and try again?
Thanks.

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

Can you try to set widget.wayland.vsync.enabled to false at about:config and restart browser and try again?
Thanks.

I disabled flag few hours ago, zero stalls, all fluid and silken smooth. But there are many changes since last check. Firefox changed version (I am on Fedota 41 -testing), also I suspect (did not remember exactly) I messed with monitor Freesync flag and corresponding GNOME control settings "Variable refresh" settings (Now both are off), also I remember there was mesa and clang updates, so it is far from scientific observation. I re enabled that buggy spy "accelerator "plugin btw, still no stalls. Need week or so experience to say more surely.

I can confirm it still freeze. I have zero freezes few days with widget.wayland.vsync.enabled=false. Now firefox updates to 136.0.1, Zero freezes about 20 min, and I tried to enable flag again (widget.wayland.vsync.enabled=true). Freeze after ~ 1 min. Another freeze after ~ 2 min of active usage.

Please try to run on terminal as:

MOZ_LOG="WidgetVSync:5" firefox

if you see the freeze, please check if Firefox is printing Vsync events to terminal. Also please copy the lines around the freeze.
Thanks.

Flags: needinfo?(stransky) → needinfo?(bradley.g.smith)

Please attach only lines around the freeze - I can't find relevant lines in a huge file.

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

Please try to run on terminal as:

MOZ_LOG="WidgetVSync:5" firefox

if you see the freeze, please check if Firefox is printing Vsync events to terminal. Also please copy the lines around the freeze.
Thanks.

Will do. A lot of log messages to terminal but no freeze so far.

(In reply to Brad Smith from comment #31)

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

Please try to run on terminal as:

MOZ_LOG="WidgetVSync:5" firefox

if you see the freeze, please check if Firefox is printing Vsync events to terminal. Also please copy the lines around the freeze.
Thanks.

Will do. A lot of log messages to terminal but no freeze so far.

I ran firefox as requested for the last 5 hours. I did not see any freeze (and have not since I updated the GPU on my Fedora workstation sometime ago). Apologies for not being more helpful.

Flags: needinfo?(bradley.g.smith)
Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Duplicate of bug: 1951249
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: