2011034 - Application menu takes five seconds or more to open

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect)

Description

[russell.s.harper]

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

Steps to reproduce:

Click on application menu (three horizontal stripes, top right)

Actual results:

Five seconds of more elapse, application menu opens.

Expected results:

It should take less than 0.5 seconds to open any UI element.

Comment 1

[BugBot [:suhaib / :marco]]

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

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

Is that a recent regression? Can you use moregression to find a broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 3

[russell.s.harper]

Please excuse the delay, I didn't realize the question was directed at me. I tried the mozregression tool and wasn't able to find the problem. I researched a bit more and found a suggestion to clear the startup cache. That seemed to fix the issue.

If your Firefox application menu (the hamburger menu) is sluggish to open, it is usually caused by corrupted cache files, conflicting extensions, or hardware acceleration issues.

Apply these quick fixes in order:

Clear Startup Cache: Open a new tab, go to about:support in the URL bar, and click the Clear startup cache button. Restart Firefox.

...

Comment 4

[russell.s.harper]

The problem has returned. Clearing the startup cache was only a temporary solution. The mozregression tool cannot duplicate the issue.

Comment 5

[russell.s.harper]

I also tried:

• Test in Troubleshoot Mode - no change
• Toggle Hardware Acceleration - made it worse

Comment 6

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

Okay. Please attach about:support from the broken version. Also is that 100% reproducible?

Please try Mozilla binaries with clean profile:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 7

[russell.s.harper]

Raw data or text?

Comment 8

[Thinker Li [:sinker]]

Either one is fine. Please save it in a file and attach it on the bug.

Comment 9

[russell.s.harper]

Attachment: support.json

Comment 10

[russell.s.harper]

JSON attached.

Comment 11

[Thinker Li [:sinker]]

Could you attach a profile captured by Firefox Profiler?

Comment 12

[russell.s.harper]

Attachment: Firefox 2026-05-22 03.22 profile.json.gz

Comment 13

[russell.s.harper]

Profile attached, also accessible via https://share.firefox.dev/4nE5XSA

/Russell

Comment 14

[Thinker Li [:sinker]]

Hi Sarah,
This bug may relate to bug #2020479 you landed recently.
Firefox hangs at isDefaultBrowserUncached while showing hamburger menu.
This function can be slow for some circumstance on linux.

Comment 15

[Mimi Jung]

(In reply to Thinker Li [:sinker] from comment #14)

Hi Sarah,
This bug may relate to bug #2020479 you landed recently.
Firefox hangs at isDefaultBrowserUncached while showing hamburger menu.
This function can be slow for some circumstance on linux.

Hi just chiming in on Sarah's behalf as I have the most context on that App Menu message. Just trying to get a bit more context, is the current speculation that isDedaultBrowserUncached is causing the performance regression to opening the app menu on Linux? It looks like this was originally filed for Fx147 but that callout landed in Fx151 and it's limited to Mac and Windows based on the message targeting:

• windows variant
• mac variant

And we're using isDefaultBrowserUncached so that the callout will un-render if the user sets the browser to default (or renders if they aren't), otherwise it would require a browser reload if we use isDefaultBrowser. We can use isDefaultBrowser and block the callout if the user shows intent by clicking on the CTA but we risk blocking the message prematurely if they don't follow through with setting to default.

Comment 16

[Manuel Bucher [:manuel]]

I observed something similar in Bug 1966047. Not sure if related though, perhaps it is completed unrelated, bringing up anyway, because the symptoms are similar. However instead of the 20s which were how long it took for the request to time out for me, we see 4s open.