1953533 - Perfomance issues when reopening a Tab group with over 200 tabs

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P3)

Description

[Rares Doghi, Desktop QA]

Attachment: largegroups.mp4

Found in

• 138.0a1 (2025-03-12)

Affected versions

• 138.0a1 (2025-03-12)

Affected platforms

• All

Steps to reproduce

1. Have a Tab group with 200 tabs.
2. Save and Close the Tab group.
3. Reopen the tab group from the list all tabs menu.

Expected result

• The tab group should be restored without any performance issues.

Actual result

• Sometimes the Firefox browser will freeze for a few seconds and it will fail to respond.

Regression range
Its not really a regression of Bug 1952902, but since the limit is no longer 25 tabs per group, we are seeing some performance issues when a lot of tabs are involved.

Here is the performance profile for this issue.
https://share.firefox.dev/4ilkmj9

Comment 1

[Stephen Thompson [:sthompson]]

We are doing the performant thing by dropping all restored tabs into the restored tab group at once, but we have an unfortunate side effect right now where each restored tab is firing a TabGrouped event and each of those causes the TOM menu all tabs list to be completely rebuilt. All of those DOM interactions in the TOM menu are causing things to chug.

https://searchfox.org/mozilla-central/source/browser/components/tabbrowser/TabsList.sys.mjs#66

We're responding to TabGrouped events in the TOM menu all tabs list in order to keep the TOM menu looking live and up to date for TOM menu users, but I guess the simple and naive "rebuild it each time" doesn't work so well when restoring a large tab group

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Yeah at least batching at requestAnimationFrame time seems it would be easy?

Comment 3

[Stephen Thompson [:sthompson]]

Attachment: Bug 1953533 - do not re-render tabs list more than once per frame r=dao,dwalker,jswinarton

The tab overflow menu's tabs list started listening for tab groups' events in order to refresh the tabs list and keep it in sync with the state of the tab strip. However, for operations that affect large tab groups all at once (restoring a closed tab group, closing a tab group), the tab group fires one event per tab all at once. This causes the tabs list to re-render itself once per tab, which is a lot of work for large tab groups.

The current use cases for the TabGrouped and TabUngrouped events do not require any context about each individual tab, so it's possible to just fire a single event when any number of tabs are added/removed at one time. This should address the performance issue with the tabs list.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/63ada92a1059
do not re-render tabs list more than once per frame r=dao,sessionstore-reviewers,tabbrowser-reviewers

Comment 5

[amarc]

https://hg.mozilla.org/mozilla-central/rev/63ada92a1059

Comment 6

[Rares Doghi, Desktop QA]

This issue is verified as fixed in our latest Nightly build 138.0a1 (2025-03-19) however, When we duplicate 120 tabs, it takes a long time for the tab strip to recover, it takes a long time to create a tab group or to open the List all tabs menu right after duplicating tabs, it might be normal ? after the websites finally load everything works great, should I log a separate issue for this ?

Comment 7

[Stephen Thompson [:sthompson]]

(In reply to Rares Doghi, Desktop QA from comment #6)

This issue is verified as fixed in our latest Nightly build 138.0a1 (2025-03-19) however, When we duplicate 120 tabs, it takes a long time for the tab strip to recover, it takes a long time to create a tab group or to open the List all tabs menu right after duplicating tabs, it might be normal ? after the websites finally load everything works great, should I log a separate issue for this ?

Yes, I think it would be helpful to track it as a separate issue. I made a performance profile while duplicating 300 tabs and most of the time is spent laying out the content of the new tabs. I don't think we have changed anything about how we handle the content of tabs, so I expect that this is a performance issue unrelated to any tab groups changes. I can confirm that the browser hangs and is unresponsive.

It looks to me like the code for duplicating tabs is asking for the newly duplicated tabs to immediately load their contents. I think it would be a good performance enhancement to only create the duplicate tabs when the user chooses to duplicate, and only have the tab contents loaded when the user selects a tab(s).

Comment 8

[Rares Doghi, Desktop QA]

Added Bug 1955049 for the separate issue.