Closed Bug 2005773 Opened 9 months ago Closed 3 months ago

Firefox using 40-50GB RAM on a single Youtube tab.

Categories

(Firefox :: Performance, defect)

Product:
Firefox
Component:
Performance
Version:
Firefox 146
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
Performance Impact ?

People

(Reporter: filotanz, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(11 files)

firefox_Y0XdJpGUzq.png
7.64 KB, image/png
Details
Gray Screen
18.96 KB, image/png
Details
Taskmgr
4.63 KB, image/png
Details
memory-report.json.gz
271.90 KB, application/x-gzip
Details
DMD.zip
4.62 MB, application/x-zip-compressed
Details
// ==UserScript== /* MIT License Copyright (c) 2025 mkco5162 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction,
56.93 KB, text/plain
Details
MOZREGRESSION_Firefox 2026-02-24 00.53 profile.json.gz
2.01 MB, application/x-gzip
Details
150.0-memory-report.json.gz
220.16 KB, application/x-gzip
Details
152.0-mozregression-memory-report.json.gz
250.80 KB, application/x-gzip
Details
Screenshots-152mozregression.zip
206.30 KB, application/x-zip-compressed
Details
DMD-memoryreport.zip
5.07 MB, application/x-zip-compressed
Details
Attached image firefox_Y0XdJpGUzq.png —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0

Steps to reproduce:

Watch a livestream on Youtube:
https://www.youtube.com/watch?v=j1jvuA16yX4

Another tab had a subframe with a Youtube video, that I didn't click to play:
https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna

The tab was in the background while I was looking at other pages. I did have a game open in the background (Diablo 4), but this issue has been reoccurring regardless if I have a game active or not for the past 6+ months.

I had only 5~ tabs open in total, which is typically the amount of tabs I have open as I close tabs I don't need.

Profiler link: https://share.firefox.dev/48z83NR

Specs:
CPU: AMD 9950x3D
GPU: GeForce RTX 5090
RAM: 64GB DDR5

Actual results:

Tab froze, gray screen with rotating loading icon visible. Only closing the tab and opening it again 'resolved' the issue.

Expected results:

Page should not have frozen and used up 80%+ of my available ram.

Attached image Gray Screen —
Attached image Taskmgr —

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Tabbed Browser
Attached file memory-report.json.gz —

It happened again on other Youtube livestream, this time I managed to get the memory report:

To accompany the memory report of previous note: https://share.firefox.dev/4q6JIVB

Crashed during a livestream:
[@ OOM | unknown | NS_ABORT_OOM | mozilla::dom::Promise::CreateInfallible | mozilla::dom::streams_abstract::SetUpReadableByteStreamController ]

https://crash-stats.mozilla.org/report/index/a7e0e20d-ab6e-47d2-89f7-f96910251213

It could be coincidental but it seems to occur much quicker when I have a game open, while Firefox is in the background(not active window) playing a livestream. During the game I would switch to browser to look up some things and switch back to the game occasionally.

Not sure how that could cause issues with GC, but I've had it happen at least twice with that being the case.

The game in specific was Diablo 4, but I've seen it happen with other games in the past as well. I don't seem to run out of resources while playing these games on their own, nor does my PC overheat or the game crash.

@Justin Link: I've seen your name pop-up in https://bugzilla.mozilla.org/show_bug.cgi?id=1549807 and several other Memory-related issues in Firefox. Maybe anything listed here can be of interest to solve these issues?

"process": "Main Process (pid 1980)",
"path": "explicit/storage/sqlite/other",
"kind": 1,
"units": 0,
"amount": 4932448,
"description": "All unclassified sqlite memory."

I took a look at the memory report and it had: 34,739.37 MB (83.68%) ── heap-unclassified in Isolated Web Content (pid 21792)

The profile shows a lot of time in: mozilla::dom::TimeoutManager::Timeouts::ForEach so we might be leaking Timeouts.

Typically the tool for diagnosing heap unclassified memory is DMD but it needs to be chosen at startup and isn't that easy to use. If you use the "Memory" preset of the profiler and gather a profile we might be able to figure out what the heap-unclassified memory is.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)

Typically the tool for diagnosing heap unclassified memory is DMD but it needs to be chosen at startup and isn't that easy to use. If you use the "Memory" preset of the profiler and gather a profile we might be able to figure out what the heap-unclassified memory is.

Tried to figure out how to get it working in a Nightly build, but the instructions are outdated or pointing to broken links. I do have the grayed out "Save DMD output" visible but obviously that is not enough. If you can provide working instructions for Windows on how to get this working I would love to do so as this issue is bugging me for over a year.

The instructions here should be up to date: https://firefox-source-docs.mozilla.org/performance/memory/dmd.html. If you run into problems we can figure out what went wrong and fix the instructions as needed.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #13)

The instructions here should be up to date: https://firefox-source-docs.mozilla.org/performance/memory/dmd.html. If you run into problems we can figure out what went wrong and fix the instructions as needed.
_

The guide assumes I know where I would set the environment variables For Firefox Nightly, I can add one to Windows's System Environment Variables, but is that really it?

I have already tried adding "--enable-dmd" to a shortcut, I already tried to add "DMD=1" to application.ini, one I copied to the browser folder and set argument to have this at the end ""-app C:\Program Files\Firefox Nightly\browser\application.ini" the browser launches using that application.ini file but doesn't result into anything.

The build/launch instructions for Windows are also from 2013 https://bugzilla.mozilla.org/show_bug.cgi?id=936784#c69 -- The instructions on that page link to a broken page of some 13 years old Firefox version, which likely would be useless in this scenario.

The rest of the page states a bunch of things that it already assumes you have knowledge of, something like:
"Build Firefox with this option added to your mozconfig:

ac_add_options --enable-dmd"

Doesn't really say much to me as it requires me to know how to build Firefox in the first place, I found the following page but are these what I should follow up if I want to build it myself? https://firefox-source-docs.mozilla.org/setup/windows_build.html

But then again, why should I build Firefox, if the page claims Nightly already has it built-in but just requires activation?

CC Artur for TimeoutManager thing as mentioned in comment #10.

Ignore my previous 2 comments, apparently it's just adding DMD=1 to System Variables of Windows itself which is sufficient enough.

Browser:
Firefox Nightly 148.0a1

Open pages:
https://www.youtube.com/watch?v=rPfpFCgfx10
https://mobalytics.gg/diablo-4/builds/sorcerer-mekuna-hydra-sorc?ws-ngf5-1=activeVariantId%2C22652c3c-4dd2-4d42-b16f-2bd61d035e77
about:memory
about:performance

The stream was ongoing in the background while playing Diablo 4, I used Windows Virtual Desktop (CTRL + WIN + LEFT/RIGHT) to switch between desktops.
Desktop #1 has Diablo 4 running
Desktop #2 has Firefox Nightly running.

Within 10 or so minutes the ram usage started ramping up, I pressed Save DMD output and Measure and Save afterwards.

I now have a bunch of files which I will combine in a zip called DMD.zip

This contains:
1: Screenshot of Windows Task Manager
2: 15x DMD files (Not sure how many were required)
3: Memory Report (manually selected)
4: Unified Memory report

The only changes compared to the base Nightly installation I made were:

  • Added the same extensions (Augmented Steam, Ublock Origin, Sponsorblock and Violentmonkey including the userscripts.
  • I imported the same set-up of Ublock Origin and Violentmonkey scripts
  • Logged into Youtube before opening the stream.
Attached file DMD.zip —

Okay after some 'extensive' testing by shutting off webpages, addons, games, userscripts I came to the realization it might happen when a specific userscript is active.

Addons turned on:
Violentmonkey

Userscript:
In previous Attached file.
The script is used to have more control and increase volume on Youtube.

Website:
https://mobalytics.gg/diablo-4/builds/sorcerer-mekuna-hydra-sorc?ws-ngf5-1=activeVariantId%2C22652c3c-4dd2-4d42-b16f-2bd61d035e77

Actions:
Opening the page.
Clicking on Windows Taskbar to unfocus Firefox.

Hovering over or scrolling inside the Skill Tree or Paragon Board elements or just mousing over one of the options in Table of contents makes the RAM ramp up even quicker. Switching between focus/unfocus seems to have some effect on it as well. I have to say these elements on it's own without any addons active are not smooth either, but that's probably something different.

Perhaps you guys can reproduce this with that website, Violentmonkey addon and the userscript on Firefox Nightly?

Turning off the userscript might stop it from happening I would have to test this some more, but perhaps this userscript is triggering a bug? Or at the very least Firefox should stop/prevent this from going out of control.

Thanks! Actually I wonder if it could be the biproduct of uBlock and YT somehow fighting each other, as somehow a huge number of crash reports involve uBlock?

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #21)

Thanks! Actually I wonder if it could be the biproduct of uBlock and YT somehow fighting each other, as somehow a huge number of crash reports involve uBlock?

Personally I was thinking because the mobalytics.gg page has an embedded Youtube video on it, combined with a livestream on another tab probably made exacerbated the issue as it was happening 'twofold' so to speak.

I tried to do the same with just Ublock Origin turned on or the other addons, but it only happened with Violentmonkey, and testing scripts one by one it started causing issues with the ** YouTube Volume Curve Designer**

I recorded a video of it happening:
https://streamable.com/0fcr24

As you can tell from the first part, it doesn't happen all the time but as soon as I scroll down the page and click on the taskbar you see it quickly ramping up... and that's with Firefox Nightly in Windows Efficiency mode as well, on regular Firefox I turned that off for better performance but likely ramps up even further.

So there's seemingly some interaction with that script that causes the ram to ramp up when the browser is not in focus and it should be something that is used in other extensions or scripts as well, as I've only been using this specific script for a few months, but I had similar issues on my previous PC when I didn't use this particular script.

Uploaded the video to Youtube as Streamable inadvertently lowered the quality of it making the text unreadable:
https://www.youtube.com/watch?v=NNYv62FLIpk

The severity field is not set for this bug.
:sclements, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sclements)

Hmm, can you try to disable or delete data leak extension?

(In reply to Elle Solomina (she/her) from comment #25)

Hmm, can you try to disable or delete data leak extension?

Data Leak Blocker? Isn't that Firefox builtin?

(In reply to Elle Solomina (she/her) from comment #25)

Hmm, can you try to disable or delete data leak extension?

If you mean disable the Userscript causing it, yes I did. After disabling that specific userscript it stopped happening, at least for the moment.
But this happened before, likely with other extensions/userscripts in the past so it's not limited to that specific one and could possibly be why other people have performance issues in Firefox as well. Perhaps this specific userscript made it far worse than other extensions/userscripts do for people.

Several questions remain however:
1: What exactly in that userscript is causing it?
2: Is that limited to very specific functionality in addons/userscripts, or is it making an existing issue worse? (Example: issues with GC)
3: Why is nothing stopping it from taking that much RAM? Aside from the tab crashing after reaching 90%+ RAM usage.
4: If the issue is caused by an extension(userscript), why is it not showing up in about:memory under the extension PID but under HEAP-UNCLASSIFIED?

I wasn’t able to reproduce this on Firefox 147.0 and Nightly 149.0a1 on Ubuntu 22.04. I tested with Violentmonkey, uBlock Origin and the YouTube Volume Curve Designer userscript enabled. I opened a YouTube livestream and an embedded iframe in separate tabs, played the livestream and left the tabs open in the background. I didn't notice any visible performance issues. I'm not able to test on Windows at the moment.

(In reply to Ina Popescu, Desktop QA from comment #28)

I wasn’t able to reproduce this on Firefox 147.0 and Nightly 149.0a1 on Ubuntu 22.04. I tested with Violentmonkey, uBlock Origin and the YouTube Volume Curve Designer userscript enabled. I opened a YouTube livestream and an embedded iframe in separate tabs, played the livestream and left the tabs open in the background. I didn't notice any visible performance issues. I'm not able to test on Windows at the moment.

Did you try like the video I posted ( https://www.youtube.com/watch?v=NNYv62FLIpk ) to scroll in the elements listed on the page while switching between focused and unfocused?

"Website:
https://mobalytics.gg/diablo-4/builds/sorcerer-mekuna-hydra-sorc?ws-ngf5-1=activeVariantId%2C22652c3c-4dd2-4d42-b16f-2bd61d035e77

Actions:
Opening the page.
Clicking on Windows Taskbar to unfocus Firefox.

Hovering over or scrolling inside the Skill Tree or Paragon Board elements or just mousing over one of the options in Table of contents makes the RAM ramp up even quicker. Switching between focus/unfocus seems to have some effect on it as well. I have to say these elements on it's own without any addons active are not smooth either, but that's probably something different."

But could be just a Windows thing or some setting I have done in Windows, as I also had an issue with Instagram reels page not loading until I set ui.prefersReducedMotion to 0 in Firefox about:config, which apparently is caused if you have Windows Animations turned off... Unfortunately that doesn't solve this issue.

I still can't reproduce this with the userscript. Can you try:

  1. Install mozregression GUI (or the python utility if you are familiar with CLI tools)
  2. Run a single build by clicking [S] icon, and click next next next and run Firefox (or if you installed the CLI tool, run mozregression --launch 2026-02-18)
  3. On this Firefox see whether you can reproduce the issue, with or without extensions. If you need to install extensions please describe the exact way to set them up. If you need to sign in, please describe that too.

This is to make sure it can be reproduced on a fresh profile, removing the chance that anything else you may have on your current Firefox could affect this.

Flags: needinfo?(filotanz)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #30)

I still can't reproduce this with the userscript. Can you try:

  1. Install mozregression GUI (or the python utility if you are familiar with CLI tools)
  2. Run a single build by clicking [S] icon, and click next next next and run Firefox (or if you installed the CLI tool, run mozregression --launch 2026-02-18)
  3. On this Firefox see whether you can reproduce the issue, with or without extensions. If you need to install extensions please describe the exact way to set them up. If you need to sign in, please describe that too.

This is to make sure it can be reproduced on a fresh profile, removing the chance that anything else you may have on your current Firefox could affect this.

Was able to reproduce this on moz-regression build 2026-02-21
https://share.firefox.dev/3OuzmkR

Had memory jump up to 15GB with two URL's open:
https://www.youtube.com/watch?v=8BtjsimL7SQ (Livestream)
https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna

.. and doing exactly what I showed in the Youtube video and described in the previous post.

Extensions installed:
uBlock Origin -> Default installation, no settings changed
Violentmonkey -> Default installation, no settings changed.. only this userscript installed: https://greasyfork.org/en/scripts/549531-youtube-volume-curve-designer

Scrolling into elements on that mobalytics page and switching between focused non-focused(click taskbar) makes the memory grow, as of writing the memory has gone up to 20GB usage and will likely continue to do so.

So it's not something I changed in the profile, it's not something I changed in the settings of any addons as it happens on Nightly builds with the bare minimum. Something in that userscript is causing the memory usage to grow with those specific pages open and not be released.

I'm not sure what else I can do to demonstrate this, as soon as I remove or disable the userscript everything works fine. So it would seem it's not hardware related.

Flags: needinfo?(filotanz)
Flags: needinfo?(sclements)
Flags: needinfo?(krosylight)

Still have problem reproducing, following comment #31 and comment #23.

As far as I can tell, the extension should only run on youtube and must not affect any other website. And the script doesn't seem to do anything special.

When you try comment #23 again with mobalytics.gg, can you also check what about:processes say? Does the memory leak happen on mobalytics.gg or on youtube.com per about:process?

And when installing ViolentMonkey, you install it from https://addons.mozilla.org/en-US/firefox/addon/violentmonkey/ and not from any third party source, right?

Flags: needinfo?(krosylight) → needinfo?(filotanz)

Mobalytics.gg has an embed of Youtube on the top right of the page, so that's likely the reason it occurs.
Violentmonkey is installed via the Mozilla Firefox Addons page, yes.
I will install the userscript later in my regular Firefox build to see if it occurs again in Firefox 150.0

However I do have to say there is so much time in between responses and each time I'm requested more and more data, but I don't have a feeling this data is being used or useful in any fashion because 4 months after reporting, and supposedly mine is not the first report either... there is still no inkling what is causing this.

Since I first reported this uBlock Origin has been updated 2 times.
Since I first reported this Violentmonkey has been updated 6 times.
Since I first reported this Firefox has been updated 11 times.

For all we know the issue has been resolved with any of these updates, from any of these sources but since so much time passes between replies, a solution seems nowhere in sight.

It also feels like I'm being gaslit, I tried it on multiple Firefox versions and it happened for months on end, then to make sure it's not some profile issue or other extensions/settings, I tried it on a mozregression build with the bare minimum and it still happened. Since removing the userscript it has not happened since, so that pretty much rules out an hardware issue.

I have about 30 other Userscripts installed, that work for various sites and only that one caused an issue. Can it be bad coding? Perhaps, I'm not a coder so I can't tell. I did pull it through ChatGPT just now and it says:

Repeated event listeners without cleanup (biggest issue)
createPanel() → setupPanelEvents()

Every time you click Save or Cancel, this happens:

this.createPanel();

But:

The old panel is not fully dereferenced
New DOM + new listeners are created every time
Old listeners stay attached to old elements until GC (which may be delayed)

Even worse:

panel.querySelector('button.cancel').addEventListener(...)
panel.querySelector('button.save').addEventListener(...)

These are re-added on every recreation.

👉 Why this leaks:

Panels are removed from DOM via Panels.hide() after transition, but:
Closures still reference configs, elements, etc.
If anything external still references them (e.g. panels.panels[name] gets overwritten but not nulled), GC can be delayed

Fix:

Reuse the panel instead of recreating it

Or explicitly remove references:

panels.panels['configs'] = null;
🔴 2. MutationObserver never disconnected
observeTitle()
observe(elements.title, function(records){ ... });
The returned MutationObserver is never stored or disconnected

👉 On SPA navigation:

This observer keeps running forever
If core.ready() is triggered multiple times (it is), you stack observers

Fix:

let titleObserver;
if (titleObserver) titleObserver.disconnect();
titleObserver = observe(...);
🟠 3. setInterval retry loop risk
getVolumeSliderWidth()
let timer = setInterval(function(){
if(rect.x === 0 || rect.width === 0)
return setTimeout(core.getVolumeSliderWidth, 1000);

Problems:

If condition keeps failing → recursive retries
Multiple intervals can stack if function is re-entered
Not all paths guarantee clearInterval(timer)

👉 Potential:

Timer buildup
Detached closures holding DOM references

Fix:

Add a max retry count
Ensure only one active interval exists
🟠 4. Global flags on DOM elements

Example:

video.gained = true;
video.listeningVolumechange = true;
muteButton.listeningMouseOver = true;

👉 Problem:

YouTube frequently replaces DOM nodes
Old nodes (with flags + listeners) can linger in memory if referenced elsewhere

Not a leak by itself, but contributes when combined with:

event listeners
closures
observers
🟠 5. AudioContext never cleaned up
createGain()
let context = new AudioContext();
No call to context.close()
On navigation → new contexts may be created

👉 Browsers usually limit AudioContexts, but:

This can still retain memory/audio graph nodes longer than needed

Fix:

Store and reuse one context
Or close it when video changes
🟡 6. Window-level listeners (low risk but permanent)

Examples:

window.addEventListener('resize', ...)
window.addEventListener('keydown', ...)

These are added once (guarded), so not a leak by themselves—but:

They persist for the entire tab lifetime
They capture closures referencing large structures (elements, configs)
🟡 7. draggable() attaches listeners per panel instance

Each panel:

element.addEventListener('mousedown', ...)
window.addEventListener('mousemove', ...)
mousemove is cleaned up on mouseup, good
But if panel is removed mid-drag → possible dangling listener

Edge case, but worth noting.

Things that are actually fine
{ once: true } on transitionend → good
clearTimeout / clearInterval used in some places → good
Guard flags like listeningVolumechange → helpful
No obvious large data structures accumulating
🧠 Real-world impact

On a typical YouTube session:

Memory usage will gradually increase
Especially if:
You open/close the config panel often
Navigate between videos a lot

Not catastrophic, but noticeable over time.

✅ Biggest fixes (priority order)

If you only fix a few things, fix these:

Disconnect MutationObserver
Stop recreating panels (reuse instead)
Ensure only one interval exists in getVolumeSliderWidth
Reuse or close AudioContext

Whether or not this is useful information, once again not a coder so can't tell. But regardless if the Userscript is badly made, a buggy extension/userscript should never be allowed to pull or cause 40-50GB of RAM usage in any given situation. That means there are no checks/limiters in place in Firefox and it just blindly keeps on using until it inevitably runs out of memory.

Flags: needinfo?(filotanz)

Had reinstalled the userscript to see if it's still happening in Firefox 150.0 as well and well... it started creeping upwards again to 22GB on a single Youtube tab..

https://share.firefox.dev/4tHhnr2

This time I only had 2 Youtube tabs open, 1 active stream and another waiting for stream. It was the waiting for stream that started using a lot of RAM instead of the one actually playing content. In both streams the users were relatively inactive in chat, so it's definitely not some chat thing.

Perhaps it's having more than one tab/element of Youtube active combined with the userscript causing the issue. Either way something in that script is running amok and Firefox is not doing anything to stop or prevent it from happening.

Do you sign in when reproducing the bug? Does it also happen when not signed in?

(I wonder this depends on some A/B test from youtube)

(In reply to Filo from comment #35)

Had reinstalled the userscript to see if it's still happening in Firefox 150.0 as well and well... it started creeping upwards again to 22GB on a single Youtube tab..

https://share.firefox.dev/4tHhnr2

This time I only had 2 Youtube tabs open, 1 active stream and another waiting for stream. It was the waiting for stream that started using a lot of RAM instead of the one actually playing content. In both streams the users were relatively inactive in chat, so it's definitely not some chat thing.

Perhaps it's having more than one tab/element of Youtube active combined with the userscript causing the issue. Either way something in that script is running amok and Firefox is not doing anything to stop or prevent it from happening.

There is a huge amount of nsCycleCollector_forgetSkippable work dealing with mozilla::dom::TimeoutManager::UnmarkGrayTimers which does a mozilla::dom::CallbackObjectBase::MarkForCC which seems to take surprisingly long each time it's called. But it seems also that there are just a lot of timers here?

I may be wrong, but if that profile shows the content process that consumed the memory, it might be that the CC/GC is slower than the piling up of the things we want to CC/GC, presumably timers?

One another thing we could try is a modified steps of comment #30:

  1. On mozregression, run a single build by clicking [S] icon, but this time you specify a directory in a "Profile selection" step. You can create an empty directory and select that.
  2. Do the repro steps
  3. After successful bug reproduction, close Firefox, and you can see the directory now has a bunch of files. Compress that directory and upload it here

This will make sure we have the exact same profile to investigate on.

If this still fails, the chance is that youtube may be behaving differently based on region etc.

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #37)

Do you sign in when reproducing the bug? Does it also happen when not signed in?

(I wonder this depends on some A/B test from youtube)

Happened in Mozregression without being signed in and on Firefox 150.0 while being signed in.

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #39)

One another thing we could try is a modified steps of comment #30:

  1. On mozregression, run a single build by clicking [S] icon, but this time you specify a directory in a "Profile selection" step. You can create an empty directory and select that.
  2. Do the repro steps
  3. After successful bug reproduction, close Firefox, and you can see the directory now has a bunch of files. Compress that directory and upload it here

This will make sure we have the exact same profile to investigate on.

If this still fails, the chance is that youtube may be behaving differently based on region etc.

https://share.firefox.dev/4cDXbAh

Profile zipped and uploaded to:
https://gofile.io/d/rXky4T

Following up on comment #38 — I think I have a plausible mechanism for both the timer pile-up and why this is so reproduction-sensitive.

Looking at the snippet from the YouTube Volume Curve Designer userscript that was quoted in comment #34:

let timer = setInterval(function(){
  if(rect.x === 0 || rect.width === 0)
    return setTimeout(core.getVolumeSliderWidth, 1000);
  ...
});

The return exits the interval callback, not the interval itself, so the original setInterval keeps ticking. Meanwhile the scheduled setTimeout calls getVolumeSliderWidth again one second later, which creates another setInterval. As long as the rect check keeps failing, the active-interval count grows multiplicatively rather than the loop just retrying in place. Each of those intervals also captures a closure with DOM and config references, which is consistent with the heap-unclassified growth and with the CC time being dominated by TimeoutManager::UnmarkGrayTimers walking every timer's callback.

Whether the rect check fails forever or resolves on the first tick is a layout condition, not a CPU one. The reporter's repro recipe — Firefox unfocused via taskbar click, mobalytics.gg with the embedded YouTube player off-screen until scrolled into view — is exactly the case where the embedded player's volume slider may never get a non-zero bounding rect, so the script stays in its retry branch indefinitely. A foregrounded test, or a slightly different YouTube player variant where the script's selector hits something that lays out immediately, will resolve on the first interval tick and clear cleanly. That likely explains why repro attempts on a different OS / fresh session / different sign-in state aren't seeing it: the runaway only starts if the slider element stays at 0×0 long enough for the second setInterval to be created.

A cheap way to confirm without DMD would be, in the affected content process's web console while the leak is in progress:

let n = 0; const _si = window.setInterval;
window.setInterval = (...a) => { n++; return _si.apply(window, a); };
setInterval(() => console.log("intervals created so far:", n), 5000);

If n is climbing super-linearly while the page is unfocused and stops climbing as soon as the embedded player is brought on-screen, that nails it down to this script's retry pattern rather than something Firefox is doing on its own.

In case this is confirmed, I am not sure if we can do much to defend against such a DoS in the cycle collector on our side. For the userscript author instead, the structural fix would be simple — the bug is that the retry uses setInterval and an inner setTimeout that re-enters getVolumeSliderWidth, which is what causes the multiplication. Picking one scheduling primitive should make the leak go away:

Option A — pure setTimeout self-retry (probably the intent):

function getVolumeSliderWidth() {
  const rect = element.getBoundingClientRect();
  if (rect.x === 0 || rect.width === 0) {
    setTimeout(getVolumeSliderWidth, 1000);
    return;
  }
  // ...use rect
}

Exactly one timer in flight at any moment.

Option B — pure setInterval that retries on its own ticks:

const timer = setInterval(() => {
  const rect = element.getBoundingClientRect();
  if (rect.x === 0 || rect.width === 0) return;   // try again next tick
  clearInterval(timer);
  // ...use rect
}, 1000);

Probably worth a note to the script authors?

(In reply to Jens Stutte [:jstutte] from comment #43)

Following up on comment #38 — I think I have a plausible mechanism for both the timer pile-up and why this is so reproduction-sensitive.

Looking at the snippet from the YouTube Volume Curve Designer userscript that was quoted in comment #34:

let timer = setInterval(function(){
  if(rect.x === 0 || rect.width === 0)
    return setTimeout(core.getVolumeSliderWidth, 1000);
  ...
});

The return exits the interval callback, not the interval itself, so the original setInterval keeps ticking. Meanwhile the scheduled setTimeout calls getVolumeSliderWidth again one second later, which creates another setInterval. As long as the rect check keeps failing, the active-interval count grows multiplicatively rather than the loop just retrying in place. Each of those intervals also captures a closure with DOM and config references, which is consistent with the heap-unclassified growth and with the CC time being dominated by TimeoutManager::UnmarkGrayTimers walking every timer's callback.

Whether the rect check fails forever or resolves on the first tick is a layout condition, not a CPU one. The reporter's repro recipe — Firefox unfocused via taskbar click, mobalytics.gg with the embedded YouTube player off-screen until scrolled into view — is exactly the case where the embedded player's volume slider may never get a non-zero bounding rect, so the script stays in its retry branch indefinitely. A foregrounded test, or a slightly different YouTube player variant where the script's selector hits something that lays out immediately, will resolve on the first interval tick and clear cleanly. That likely explains why repro attempts on a different OS / fresh session / different sign-in state aren't seeing it: the runaway only starts if the slider element stays at 0×0 long enough for the second setInterval to be created.

A cheap way to confirm without DMD would be, in the affected content process's web console while the leak is in progress:

let n = 0; const _si = window.setInterval;
window.setInterval = (...a) => { n++; return _si.apply(window, a); };
setInterval(() => console.log("intervals created so far:", n), 5000);

If n is climbing super-linearly while the page is unfocused and stops climbing as soon as the embedded player is brought on-screen, that nails it down to this script's retry pattern rather than something Firefox is doing on its own.

In case this is confirmed, I am not sure if we can do much to defend against such a DoS in the cycle collector on our side. For the userscript author instead, the structural fix would be simple — the bug is that the retry uses setInterval and an inner setTimeout that re-enters getVolumeSliderWidth, which is what causes the multiplication. Picking one scheduling primitive should make the leak go away:

Option A — pure setTimeout self-retry (probably the intent):

function getVolumeSliderWidth() {
  const rect = element.getBoundingClientRect();
  if (rect.x === 0 || rect.width === 0) {
    setTimeout(getVolumeSliderWidth, 1000);
    return;
  }
  // ...use rect
}

Exactly one timer in flight at any moment.

Option B — pure setInterval that retries on its own ticks:

const timer = setInterval(() => {
  const rect = element.getBoundingClientRect();
  if (rect.x === 0 || rect.width === 0) return;   // try again next tick
  clearInterval(timer);
  // ...use rect
}, 1000);

Probably worth a note to the script authors?

Interesting analysis, the userscript author has not responded to an earlier attempt to contact them, but it also was not very clear what exactly was causing it.

While I get it's not feasible to build in individual checks for each types of (bad) code writing, would it not be preferable for Firefox to halt and warn the user about the escalating RAM usage due to a repetitive pattern? Like the "A webpage is slowing down your browser, what would you like to do?" message you get in other circumstances? Or a soft crash/unload tab scenario.

We're heading to a day and age where people are going to write their own extensions/userscripts using AI, so I have no doubts that there will be a lot more reports coming in about Firefox using a lot of resources.

I wonder if there is any circumstances where a browser would use more than 5GB RAM on a single page, I have personally never seen any page consume more than 1-2GBRAM at any given time... and definitely not somewhere in the range of 20GB+ on a single tab.

The problem is that this JS DoS manifests in a weird way through our CycleCollector, probably bypassing the slow script detection by blocking the main thread in an internal loop that cannot be easily interrupted and that normally is believed to be very fast. I agree we should think of doing something to defend ourselves better, I am though unsure how much we could prioritize this and what this could actually look like.

(In reply to Jens Stutte [:jstutte] from comment #43)

Whether the rect check fails forever or resolves on the first tick is a layout condition, not a CPU one. The reporter's repro recipe — Firefox unfocused via taskbar click, mobalytics.gg with the embedded YouTube player off-screen until scrolled into view — is exactly the case where the embedded player's volume slider may never get a non-zero bounding rect, so the script stays in its retry branch indefinitely. A foregrounded test, or a slightly different YouTube player variant where the script's selector hits something that lays out immediately, will resolve on the first interval tick and clear cleanly. That likely explains why repro attempts on a different OS / fresh session / different sign-in state aren't seeing it: the runaway only starts if the slider element stays at 0×0 long enough for the second setInterval to be created.

But can you reproduce it? Even with the uploaded profile I still cannot, with mozregression --profile (unzipped profile path) --profile-persistence clone --launch 2026-04-28 -a https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna

It all sounds plausible until you see setInterval is never even called per devtools.

In devtools console I see the script just bails out without actually calling the relevant function getVolumeSliderWidth.

Uncaught (in promise) Error: Not found: chromeBottom, I give up.
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:774
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    setTimeout handler*apply https://www.youtube.com/embed/GR2XGtqfPoM?autoplay=0&mute=0&controls=1&origin=https://mobalytics.gg&playsinline=1&showinfo=0&rel=0&iv_load_policy=3&modestbranding=1&enablejsapi=1&widgetid=1&forigin=https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna&aoriginsup=1&vf=1:817
    get moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:773
    getTarget moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:779
    getTarget moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:778
    getTargets moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:785
    getTargets moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:785
    <anonymous> debugger eval code:1
    readyForVideos moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:314
    promise callback*readyForVideos moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:306
    ready moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:290
    promise callback*ready moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:279
    initialize moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:272
    VMp9sup681l37 moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:1482
    VMp9sup681l37 moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:1484
    VMp9sup681l37 moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:1485
    on moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/sandbox/injected-web.js:1
    <anonymous> moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/ YouTube Volume Curve Designer.user.js#1:1
    Se moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/sandbox/injected-web.js:1
    post moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/sandbox/injected-web.js:1
    ScriptData moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/sandbox/injected-web.js:1
    onHandle moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/sandbox/injected-web.js:1
    Ee moz-extension://3ecff0aa-d771-4024-84bd-8d329a0503a6/sandbox/injected-web.js:1
GR2XGtqfPoM:774:28

No, I did not try to reproduce, I was coming from what the profile tells (and it seems clear we are seeing a ton of timers, but I have no direct proof they come from that snippet). Is there an easy way that the reporter can modfiy the userscript as suggested to try it out ?

Component: Tabbed Browser → Performance

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #46)

(In reply to Jens Stutte [:jstutte] from comment #43)

Whether the rect check fails forever or resolves on the first tick is a layout condition, not a CPU one. The reporter's repro recipe — Firefox unfocused via taskbar click, mobalytics.gg with the embedded YouTube player off-screen until scrolled into view — is exactly the case where the embedded player's volume slider may never get a non-zero bounding rect, so the script stays in its retry branch indefinitely. A foregrounded test, or a slightly different YouTube player variant where the script's selector hits something that lays out immediately, will resolve on the first interval tick and clear cleanly. That likely explains why repro attempts on a different OS / fresh session / different sign-in state aren't seeing it: the runaway only starts if the slider element stays at 0×0 long enough for the second setInterval to be created.

But can you reproduce it? Even with the uploaded profile I still cannot, with mozregression --profile (unzipped profile path) --profile-persistence clone --launch 2026-04-28 -a https://mobalytics.gg/diablo-4/profile/mekuna/builds/hydra-leveling-1-60-mekuna-s-hydrakuna

It all sounds plausible until you see setInterval is never even called per devtools.

Can you try with two Youtube livestreams open, one playing content and the other one that is planned such as:
https://www.youtube.com/watch?v=wPXfKeWU2YE

What I did is switch tabs, click on some elements in the tabs without clicking on something that refreshes the page or change to another video, on the planned stream you can click a bunch of times in the 'video'/still image. Then click on Taskbar to lose focus or have some always on top application in front of it, in my case it can be Task manager or a game.

It's finicky and it doesn't happen straight away, even if I attempt it sometimes doesn't show any difference straight away, it just gradually grows over time, at some points there are sudden spikes where it jumps 1-3GB at once, but for the most part it goes a few hundred MB per 30-60 seconds until at some point you notice it's going towards 10GB+

What I find strange is that it doesn't occur for you even under the same conditions/same profile etc. --- I wouldn't think OS or hardware should matter for this issue as that should make no difference for GC in a browser, right?

(In reply to Jens Stutte [:jstutte] from comment #48)

No, I did not try to reproduce, I was coming from what the profile tells (and it seems clear we are seeing a ton of timers, but I have no direct proof they come from that snippet). Is there an easy way that the reporter can modfiy the userscript as suggested to try it out ?

I have not tried that out yet, just need to figure out why it is relatively easily for me to reproduce and not for others.

I realized only now that we have a DMD report from comment 18 on this bug and spent a few more tokens to look into it:

After symbolicating against the matching 148.0a1 build (20260106100019) and re-running dmd.py, the Jan 6 DMD snapshot of the youtube.com content process (PID 14240, ~18.8 GB resident) breaks down like this:

  • The leak is concentrated in one realm: the YouTube embed iframe https://www.youtube.com/embed/BHIb20_bOzo on the mobalytics page. That single iframe's GC heap holds ~639 MB of LexicalEnvironment objects and ~409 MB of Function objects — on the order of ~10M live closures.
  • On the C++ side, the live-block records under Window_Binding::setInterval and Window_Binding::setTimeout together account for ~5.0 GB of source-location strings (CallbackTimeoutHandler ctor → JSCallingLocation::Get) and ~500 MB of Timeout object allocations from TimeoutManager::SetTimeout (dom/base/TimeoutManager.cpp:522). The split is ~6M setInterval callsites vs ~3.7M setTimeout callsites (~1.6:1).

So the timer-pile-up reading from comment #43 holds, with the caveat that both setInterval and setTimeout were active in the runaway, not just one — so the precise mechanism may be a fan-out across multiple targets rather than a single retry chain.

As this is based on a snapshot four months old, if this still reproduces reliably for you, two artifacts may help, taken in separate sessions:

  1. A fresh DMD.zip, captured the same way as comment #18 (set DMD=1 in your Windows System Variables, reproduce the leak, then "Save DMD output" + "Measure and Save"). This will tell us whether the call-site distribution still looks the way it did in January, or whether something has shifted.
  2. A separate profile without DMD=1 set — just use the profiler's Memory WebCompat preset on a clean Nightly with the userscript active, reproduce the leak, and share the link. The reason for asking for this separately is that DMD itself adds significant per-allocation bookkeeping (about 5.6 GB of explicit/dmd/live-block-table overhead in the Jan 6 snapshot, plus very high reporter traffic). For diagnosing the runaway timing and CC slice cost, a non-DMD profile is much more representative of what users actually experience. The earlier the profiling starts to capture the adding of the timers, the better.

Thank you for your patience!

Would be easier to figure out if we have a profile with JS. Can you try getting a performance profile with WebCompat preset? That one is designed to capture every JS call so that we can see who's calling what.

(In reply to Jens Stutte [:jstutte] from comment #48)

No, I did not try to reproduce, I was coming from what the profile tells (and it seems clear we are seeing a ton of timers, but I have no direct proof they come from that snippet). Is there an easy way that the reporter can modfiy the userscript as suggested to try it out ?

... so that we can have a direct proof.

If we can prove that the userscript is the culprit indeed, then the next question would be, how come it gets a zero size to trigger the bad recursion. If we can disprove it and it actually comes from somewhere else, that would also be interesting.

Example profile: https://share.firefox.dev/4t6fjrt

Flags: needinfo?(filotanz)
Attached file DMD-memoryreport.zip —
Flags: needinfo?(filotanz)

I tried to do the webcompat profiling but it is unclear if it captured the issue happening as the profiling itself filled up the memory rapidly towards like 57GB within 1-2 minutes:
https://share.firefox.dev/3QFKLiR

So I tried to do what I usually do to replicate it, but it's unclear if it actually captured it in this.

Over to saschanaz now that the profile is posted.

Performance Impact: --- → ?
Flags: needinfo?(krosylight)

Ah, thanks for needinfo. Quick look at the profile shows that the profile is filled up with a big number of setTimeout. But it's not running extension code, it's all calling YouTube scripts.

https://profiler.firefox.com/public/jv6h2sa6z4yws7vchq843kx8kpww3pz40ynaq40/calltree/?globalTrackOrder=0dba1w9c&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=4704-0w2~28616-0~26664-01&implementation=js&thread=i&v=16

Can't tell whether it's setTimeout recursion or whether it's called repeatedly by something else.

I do see uBO calling setTimeout in a few places too, in a MutationHandler https://profiler.firefox.com/public/jv6h2sa6z4yws7vchq843kx8kpww3pz40ynaq40/calltree/?globalTrackOrder=0dba1w9c&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=4704-0w2~28616-0~26664-01&implementation=js&search=setTimeout&thread=i&v=16, could it be that uBO somehow is triggering YouTube script?

Also Filo, I know I'm asking repeately, does this still happening today? YouTube shipped a layout related fix related to https://bugzilla.mozilla.org/show_bug.cgi?id=2035904, I wonder whatever that was causing that also was the culprit here. (I could not reproduce that either, people saw different behaviors.)

Keeping NI for further investigation.

Flags: needinfo?(krosylight) → needinfo?(filotanz)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #55)

Keeping NI for further investigation.

Keeping this one as well, though an update on whether youtube has since fixed this would be helpful as well, Filo, if possible? Thank you!

Flags: needinfo?(krosylight)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #55)

Ah, thanks for needinfo. Quick look at the profile shows that the profile is filled up with a big number of setTimeout. But it's not running extension code, it's all calling YouTube scripts.

https://profiler.firefox.com/public/jv6h2sa6z4yws7vchq843kx8kpww3pz40ynaq40/calltree/?globalTrackOrder=0dba1w9c&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=4704-0w2~28616-0~26664-01&implementation=js&thread=i&v=16

Can't tell whether it's setTimeout recursion or whether it's called repeatedly by something else.

I do see uBO calling setTimeout in a few places too, in a MutationHandler https://profiler.firefox.com/public/jv6h2sa6z4yws7vchq843kx8kpww3pz40ynaq40/calltree/?globalTrackOrder=0dba1w9c&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=4704-0w2~28616-0~26664-01&implementation=js&search=setTimeout&thread=i&v=16, could it be that uBO somehow is triggering YouTube script?

Also Filo, I know I'm asking repeately, does this still happening today? YouTube shipped a layout related fix related to https://bugzilla.mozilla.org/show_bug.cgi?id=2035904, I wonder whatever that was causing that also was the culprit here. (I could not reproduce that either, people saw different behaviors.)

Keeping NI for further investigation.

(In reply to :Gijs (he/him) from comment #56)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #55)

Keeping NI for further investigation.

Keeping this one as well, though an update on whether youtube has since fixed this would be helpful as well, Filo, if possible? Thank you!

Have added the userscript to Youtube for a day on my regular Firefox installation(150.0.3) and tested it out on Fresh Profile on Nightly including Ublock Origin, it doesn't seem to occur anymore. At least I have not seen any excessive spikes in RAM usage and was not able to trigger it anymore.

What I find strange however is that without the userscript I had no issues on Youtube before, while the other reports suggest people were having these issues without the specific userscript (presumably) and they have only started having issues in the past 2-3 weeks. Whereas for me it was an issue that I was experiencing for the past few months as soon as I used the userscript.

Flags: needinfo?(filotanz)

It's possible that YouTube did some experiment on a small cohort and then started to expand that to more people, leading to more bug reports. It's frustrating when users report issues and we just cannot get access to the exact same situation...

Very happy that you don't get the issue anymore, after months of frustration 😖

Big Thank You for staying with us so far! 🥰 (even though we couldn't give you much help immediately)

Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Flags: needinfo?(krosylight)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: