Native macOS menus load every bookmark favicon when Spotlight opens the menubar without showing it
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox162 | --- | fixed |
People
(Reporter: spohl, Assigned: spohl)
References
Details
(Keywords: perf)
Attachments
(1 external file)
On macOS 26 and later, Spotlight asks running apps for their menu commands. AppKit then opens every menu in the menubar without showing it (-[NSMenu _simulateOpening:]). For users with many bookmarks, Firefox builds every bookmark menu item and loads and draws its favicon during these passes, which can keep the main thread busy for many seconds after pressing Cmd+Space. Bookmarks without a stored favicon each get the default SVG icon under their own page-icon: URI, so every one of them becomes a separate image document.
Bug 2002102 and bug 2086594 limit the number of entries in each native menu, but the reporter in bug 2086594 (about 100,000 bookmarks in more than 1,000 folders) still sees hangs of up to a minute. Their profiles in bug 2086594 comment 10 show most of the time in nsMenuItemIconX::OnComplete and in loading the SVG image documents.
The proposed fix keeps building the menu items during these simulated opens, so Spotlight still sees them, but defers the icon loads until a menu is actually shown. I considered adding a pref for this change, but I don't believe that this is necessary in this instance. Please let me know if I should reconsider.
| Assignee | ||
Comment 1•17 hours ago
|
||
Spotlight on macOS 26 and later makes AppKit open every menu in the menubar without showing it (-[NSMenu _simulateOpening:]) to collect the app's menu commands. With many bookmarks, every item then loaded and drew its favicon, which kept the main thread busy for seconds after the menus had closed again.
The menu items are still built during these simulated opens, so Spotlight still sees them, but their icon loads now wait until the menu is actually shown.
Comment 3•11 hours ago
|
||
Having seen the latest Nightly build go out a few minutes ago I updated, but unfortunately the bug doesn't appear to have been affected. The hanging issue upon hitting Cmd+spacebar still lasts about two minutes, although the sequence of events (spinning beach ball vs stuttering/"after shock" freezes) slightly differ, as they generally do.
Here's a profile via the latest build:
Comment 4•6 hours ago
|
||
| bugherder | ||
Description
•