1969253 - Firefox freezes when trying to open any palette

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[quadronom]

Attachment: freeze.txt

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0

Steps to reproduce:

Not sure what has changed but 139 is probably the most unstable Firefox version.
Even just trying to open the uBlock palette (by clicking on their logo) will freeze Firefox. Unrecoverable. Renderer deadlocks itself (see attached macOS log).

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance: General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[quadronom]

Oh dear, it's much worse than that. Firefox will freeze anytime something is opened. Even like Firefox MultiContainers will do that. :((

Comment 3

[quadronom]

139.0.1 did not change anything. Firefox freezes.

Comment 4

[Haik Aftandilian [:haik]]

Moving this to the Graphics Component.

The attached Activity Monitor log shows the parent process main thread in CoreAnimation code callbacks for the full 1.8 seconds of the sampling time. The sampler is labeling the hang as a deadlock involving the "Renderer" thread.

Comment 5

[quadronom]

While browsing itself "works" this is a pretty severe defect and impairs proper usage (e.g. whenever I need to disable the ad-blocker for whatever reason).
Any chance somebody can have a look at this?
I'll gladly provide more data – if you point me in the right direction / tell what you need.

Comment 6

[Markus Stange [:mstange]]

Hi, could you try to capture a profile of this with the Firefox profiler? The profiler can be started and stopped even when the Firefox UI is hung, using signals: https://profiler.firefox.com/docs/#/./async-posix-signal-control

Comment 7

[quadronom]

That’s nice! I didn’t know this was possible, perfect! Thanks for pointing that out.
Please see the following:

https://share.firefox.dev/43Mkxy4
This first one is with the general „Firefox“ setting and it „successfully“ hang after trying to open the uBlock palette.

https://share.firefox.dev/45aH2z7
Second one with the „graphics“ setting. Here a big chunk is red = jank.

I hope it helps and you identify the issue! I can always make more of these if you need that.

Comment 8

[Markus Stange [:mstange]]

[Tracking Requested - why for this release]: Irrecoverable UI hang in certain configurations on macOS

Thanks! This is a deadlock and it must have been introduced recently. Nical, might it have been introduced by bug 1961115?

Comment 9

[Markus Stange [:mstange]]

quadronom, do you have any gfx.webrender prefs set to non-default values, for example the gfx.webrender.compositor pref?

Comment 10

[quadronom]

Yes it must happened between 138 and 139, I'd say. I never had this issue before.

Let's have a look at my non-default values:

• gfx.webrender.all => true
• gfx.webrender.compositor => false
• gfx.webrender.precache-shaders => true

The rest has not been altered.

Comment 11

[Markus Stange [:mstange]]

Ah, I think I know what the bug is.

It's not really a deadlock, it's more of an "unbalanced" lock. Unfortunately it seems that the calls to PreRender and PostRender need to be perfectly balanced, otherwise you call .Lock() twice and you're done. This is super fragile.

https://phabricator.services.mozilla.com/D245565 added an early return path where PreRender is called but PostRender is not, in the case where both rendered and present are false.

Comment 12

[Markus Stange [:mstange]]

Actually no, that explanation isn't the full story. Need to look into it more.
If present is false then we also don't call PreRender, so there is no imbalance.

Comment 13

[Markus Stange [:mstange]]

Ah, this is the new early return that was introduced where we don't call PostRender at all:

https://searchfox.org/mozilla-central/rev/60f924edfedc19cd16a30251053513c08bba149c/gfx/webrender_bindings/RendererOGL.cpp#207-211

if (!beginFrame) {
  CheckGraphicsResetStatus(gfx::DeviceResetDetectPlace::WR_BEGIN_FRAME,
                           /* aForce */ true);
  return RenderedFrameId();
}

Comment 14

[Markus Stange [:mstange]]

And beginFrame is false because we probably hit this early return in RenderCompositorNative::BeginFrame() for popup windows that don't know their size yet:

https://searchfox.org/mozilla-central/rev/60f924edfedc19cd16a30251053513c08bba149c/gfx/webrender_bindings/RenderCompositorNative.cpp#62-66

gfx::IntSize bufferSize = GetBufferSize().ToUnknownSize();
if (!ShouldUseNativeCompositor()) {
  if (bufferSize.IsEmpty()) {
    return false;
  }

Comment 15

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1961115

:nical, since you are the author of the regressor, bug 1961115, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 16

[Markus Stange [:mstange]]

The patch is simple but Phabricator is currently down so I can't upload it.

Comment 17

[Markus Stange [:mstange]]

Attachment: Bug 1969253 - Reintroduce PostRender call that was incorrectly removed in D245565. r=gw

Calling PreRender twice without a PostRender call in between causes us to hit a deadlock.
BeginFrame can return false when called for windows that are still in the process of
being opened, during which time they return a size of 0x0.

Comment 18

[Markus Stange [:mstange]]

Steps to reproduce (macOS only):

1. On about:config, set gfx.webrender.compositor to false
2. Restart to apply the pref
3. Click the Pocket button in the toolbar, or alternatively click any button that opens a panel whose contents are rendered by an add-on.

Expected results: Normal operation
Actual results: Perma-hang

Comment 19

[Markus Stange [:mstange]]

Attachment: Bug 1969253 - Call PostRender on all execution paths where PreRender was called. r=gw

Calling PreRender twice without a PostRender call in between causes us to hit a deadlock.
BeginFrame can return false when called for windows that are still in the process of
being opened, during which time they return a size of 0x0.

A new early return without a PostRender call was added in https://phabricator.services.mozilla.com/D245565 .

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/682f29c06fd5
https://hg.mozilla.org/integration/autoland/rev/db3b765e4001
Call PostRender on all execution paths where PreRender was called. r=gw

Comment 21

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/db3b765e4001

Comment 22

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:mstange, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox140 to wontfix.

For more information, please visit BugBot documentation.

Comment 23

[Markus Stange [:mstange]]

Attachment: Bug 1969253 - Call PostRender on all execution paths where PreRender was called. r=gw

Calling PreRender twice without a PostRender call in between causes us to hit a deadlock.
BeginFrame can return false when called for windows that are still in the process of
being opened, during which time they return a size of 0x0.

A new early return without a PostRender call was added in https://phabricator.services.mozilla.com/D245565 .

Original Revision: https://phabricator.services.mozilla.com/D252243

Comment 24

[Markus Stange [:mstange]]

Requested Beta uplift on https://phabricator.services.mozilla.com/D252346 .

Comment 25

[Markus Stange [:mstange]]

quadronom, this fix should be in today's Firefox Nightly. Can you download a Firefox Nightly from https://nightly.mozilla.org/ and check if the problem still occurs in that build? The patch may also have fixed bug 1969010, so please check that one too.

Comment 26

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: UI hangs on Windows and macOS in some circumstances
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: We don't have steps to reproduce for the Windows hang (bug 1969346). For the macOS hang:1. On about:config, set gfx.webrender.compositor to false 2. Restart to apply the pref 3. Click the Pocket button in the toolbar, or alternatively click any button that opens a panel whose contents are rendered by an add-on, such as the uBlock Origin toolbar panel.
• Risk associated with taking this patch: low
• Explanation of risk level: Conservative fix which restores previous behavior
• String changes made/needed: none
• Is Android affected?: no

Comment 27

[Markus Stange [:mstange]]

Attachment: Bug 1969253 - Call PostRender on all execution paths where PreRender was called. r=gw

Calling PreRender twice without a PostRender call in between causes us to hit a deadlock.
BeginFrame can return false when called for windows that are still in the process of
being opened, during which time they return a size of 0x0.

A new early return without a PostRender call was added in https://phabricator.services.mozilla.com/D245565 .

Original Revision: https://phabricator.services.mozilla.com/D252243

Comment 28

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: UI hangs on Windows and macOS in some circumstances
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: We don't have steps to reproduce for the Windows hang (bug 1969346). For the macOS hang:1. On about:config, set gfx.webrender.compositor to false 2. Restart to apply the pref 3. Click the Pocket button in the toolbar, or alternatively click any button that opens a panel whose contents are rendered by an add-on, such as the uBlock Origin toolbar panel.
• Risk associated with taking this patch: low
• Explanation of risk level: Conservative fix which restores previous behavior
• String changes made/needed: none
• Is Android affected?: no

Comment 29

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/9cff078efd96
https://hg.mozilla.org/releases/mozilla-beta/rev/0268a163aab2

Comment 30

[Bogdan Maris, Desktop Test Engineering]

Reproduced the hang using an old Nightly build from Nightly 2025-05-29, verified that using latest Nightly build 141.0a1 and the latest Beta 140 build from treeherder on macOS 13 that there is no hang when opening a panel from an addon.

Comment 31

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/e2de761c1d5b
https://hg.mozilla.org/releases/mozilla-release/rev/69d67d8e0f8f

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Added to the 139.0.4 relnotes.

Fixed Firefox freezing when switching between apps or opening certain panels within the browser.

Comment 35

[Bogdan Maris, Desktop Test Engineering]

Also verified that this is fixed using Firefox 139.0.4 across platforms (MacOS 13, Ubuntu 22.04 and Windows 11).