Open Bug 1954839 Opened 1 month ago Updated 7 days ago

Constantly creating (discarded) tabs will cause them to get slower and slower until they freeze

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Firefox 138
defect

Tracking

()

Tracking Status
firefox136 --- affected
firefox137 --- affected
firefox138 --- affected

People

(Reporter: rrrrre123, Unassigned, NeedInfo)

Details

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

Steps to reproduce:

I use the webextension api browser.tabs.create to constantly create tabs:

browser.browserAction.onClicked.addListener(async () => {
try {
const newWindow = await browser.windows.create({
url: "about:blank",
type: "normal"
});

const tabCount = 2000; 
const baseUrl = "https://example.com/?tab=";

for (let i = 0; i < tabCount; i++) {
  await browser.tabs.create({
    url: baseUrl + i,
    windowId: newWindow.id,
    active: false,
    discarded:true
  });
}

} catch (error) {
console.error(error);
}
});

Actual results:

https://share.firefox.dev/43RBbOk

Expected results:

Complete quickly without slowing down or freezing

Component: Untriaged → Layout
Product: Firefox → Core

Tentatively moving to WebExtensions, this doesn't look like a layout issue.

Component: Layout → General
Product: Core → WebExtensions

Hello,

I ran the extension with the background script you provided and indeed the process of creating discarded tabs gets slower and slower as the tabs are created (visibly seen by the arrow at the right of the tabs blinking slower and slower), however on my end they don’t freeze. The process completes successfully when reaching 2000 discarded tabs with https://example.com/ .

In case it matters, on my end, CPU was at ~35% and RAM usage at ~ 1GB during the process.

Tested on the latest Nightly (138.0a1/20250326192415), Beta (137.0/20250325171416) and Release (136.0.320250324135651) under Windows 11.

Although I cannot reproduce the freeze, I will mark this issue as NEW for the slowing down of tabs creation.

Status: UNCONFIRMED → NEW
Ever confirmed: true

I suspect that this issue is independent of extensions; extensions just make it easier to bulk-create many tabs. If you were to user other forms of browser automation such as WebDriver, I expect that you would see similar results.

The profile shows lots of activity in layout code. I'm therefore moving this bug to Layout for further triage.

Component: General → Layout
Product: WebExtensions → Core

Looks like an awful lot of time is spent in stylo; moving to that component for consideration.

Component: Layout → CSS Parsing and Computation

Each restyle is styling 20k / 30k elements. A tab has 19 elements so it doesn't seem too crazy of a number / seems consistent with the number in comment 0.

It seems basically inserting a tab in the tabstrip does invalidate style linearly on the number of tabs. I'm betting on this selector (and the other similar to it) triggering what in this case seems to be over-invalidation. But just a hunch.

I can take a look at what exactly is causing this when I have the time but seems relatively low priority.

Severity: -- → S3
Flags: needinfo?(emilio)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.