Firefox's "List all tabs" menu janks for a long time if you have hundreds of tabs open with large-filesize favicons (e.g. bugzilla)
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
Performance Impact | ? |
People
(Reporter: dholbert, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
tl;dr the "List all tabs" menu can be super-expensive to open. (I noticed this because we're showing a tab-groups onboarding pop-up, which points users to the "List all tabs" menu as part of its instructions; I tried the list-all-tabs menu and was surprised at how slow it was to open in my regular browsing profile.)
The real-world STR are to open the "list all tabs" menu in a Firefox window where you have hundreds of bugzilla tabs, by e.g. following instructions in bug 1867161 comment 0. But probably don't actually do that because generating such a window may send a ton of traffic to Bugzilla all at once, which isn't nice to the Bugzilla servers. So I'm providing friendlier STR, using a local web server with an extra-expensive bugzilla favicon, based on bug 1867161 comment 3.
STR:
-
Follow steps 1-4 of bug 1867161 comment 3 (to open a window with 500 tabs that are using an extra-heavyweight version of the Bugzilla favicon.
Note: this occasionally fails to get me a window with 500 tabs - I sometimes just saw 2 tabs of Firefox's firstrun pages instead -- but if that happens, you can still get a window with 500 tabs by doing Ctrl+N, or quitting & restarting Firefox with that same profile.) -
Click the "List all tabs" menu dropdown-arrow at the right end of your tabstrip.
ACTUAL RESULTS:
Seconds-long jank before the menu opens.
EXPECTED RESULTS:
No such jank.
Reporter | ||
Comment 1•1 month ago
|
||
My STR here are admittedly a bit over-dramatic to make this easier to see, but only just a bit. In particular:
- Having 500 bugzilla tabs might be outside the norm for most users (but it's definitely reflective of the real experience of Firefox developers).
- I scaled up the size of the bugzilla favicon in my "test environment" here by 10x as compared to the real bugzilla favicon, to make the pain ~10x worse than it would otherwise be. (But even without that, bugzilla's favicon is quite large (see bug 1944091) which makes this easy to run into with actual-Bugzilla if you have enough tabs open).
Reporter | ||
Comment 2•1 month ago
•
|
||
Here's a profile where I followed the STR here and then clicked "List All Tabs" twice resulting in two large jank areas:
https://share.firefox.dev/4jwMwsA
(Some of the jank time is spent in sessionstore which is bug 1849393; I've done "drop samples with this function" for sessionstore writes, to avoid those sample muddying up the time that we're considering here; and then I further did "focus on function" for XULPopupElement.openPopup
to only focus on the time in there).
This time is essentially all reported as an ~8-second style flush, which is almost entirely spent in nsImageFrame::UpdateXULImage
, which itself is ~70% spent in NS_NewURI
and ~30% spent in nsContentUtils::LoadImage
. All of that work seems to be stuff that's proportional-to-the-length-of-the-URI, which is why it's so heavyweight here when we're dealing with extremely long data URIs for files on the order of hundreds of kilobytes.
Probably the most direct way to avoid repeating that work would be for the tab-strip to be using shorter URIs here (e.g. blob URIs) for the favicons, if that's possible...
Updated•27 days ago
|
Comment 3•22 days ago
|
||
Asking for perf impact evaluation; we're guessing this might be low due to this being limited to specific sites with large favicons, that the user has opened a lot of times in the current window.
Comment 4•15 days ago
|
||
The severity field is not set for this bug.
:dao, could you have a look please?
For more information, please visit BugBot documentation.
Updated•15 days ago
|
Comment 5•14 days ago
|
||
The severity field is not set for this bug.
:dao, could you have a look please?
For more information, please visit BugBot documentation.
Description
•