Constantly creating (discarded) tabs will cause them to get slower and slower until they freeze
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
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
Comment 1•1 month ago
|
||
Tentatively moving to WebExtensions, this doesn't look like a layout issue.
Comment 2•1 month ago
|
||
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.
Comment 3•28 days ago
|
||
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.
Comment 4•14 days ago
|
||
Looks like an awful lot of time is spent in stylo; moving to that component for consideration.
Comment 5•7 days ago
|
||
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.
Comment 6•7 days ago
|
||
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.
Comment 7•7 days ago
|
||
I can take a look at what exactly is causing this when I have the time but seems relatively low priority.
Description
•