version 133 has messed up YouTube , the worst is memory/CPU spikes
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
People
(Reporter: jenwolf, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(9 files)
Screenshot 2024-12-11 053537.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Steps to reproduce:
I just watch YouTube videos.
Actual results:
Since version 133 and YouTube has so many bugs, and it is only YouTube, as I didn't notice such behavior with other sites.
As I believe all these issues are caused by the same cause, I will start only one bug report, and I believe it has something to do with this change "Canvas2D switched from Direct2D to a platform independent acceleration backend on Windows
"
1- At least double of the memory is used now for videos. Videos I used to watch before will take about 500MB RAM, now it is almost 1GB if not more for the same videos.
2- Sometimes Firefox doesn't evict memory when closing YouTube tabs which never happened before version 133. Even worse sometimes Firefox will use more memory when closing YouTube tab see pic 01 for not evicting the memory, pic 02 and 03 where the memory will increase when closing YouTube tabs, sometime it will evict the memory when closing tabs, see pic 04 and 05
3- The worst of all is weird spikes for memory/CPU usage even for inactive YouTube tabs, see attached pics 08 to 16. the worst case there was inactive tab for the main page youtube.com with no other tabs sharing the same process, and there was huge memory/CPU and what made notice this is that the CPU fans in my laptop started making loud noises so I checked and it was the only one inactive tab opened. see pic 17.
Performing GC, CC or Minimize memory usage will do nothing to you tube tabs except of high CPU usage for these tabs without affecting the memory used.
I have super fast laptop i9 13950hx with 128gb and NVIDIA RTX ADA 5000, and I never though that watching YouTube videos will be a pain.
Expected results:
1- memory usage should not be doubled
2- FF should always evict memory when closing YouTube tabs, and for sure memory will not increase when closing tabs
3- There should be no memory/CPU spikes for active or inactive tabs.
|
||
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::JavaScript: GC' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 months ago
|
I updated my VP9/AV1 extensions and installed FF beta8 version 134.0.0.1333 and I am still encountering the issue. Almost few minutes and one process starting making these spikes for an inactive YouTube tab
I just wanna say that not all YouTube processes show these weird spikes, not at first at least. It will take time, and all processes can make these spikes
I set dom.ipc.processCount.webIsolated to 32 (it was default 4) so I make sure it is one process for each YouTube tab, so when I close the tab the process will be closed, as there is no guarantee that the FF will evict the memory when closing YouTube tabs.
Check the new attachment Screenshot 2024-12-11 053537 for version 134 beta8.
not sure if it helps also, I set media.mediasource.eviction_threshold.video to 1GB and media.mediasource.eviction_threshold.audio to 200MB to make sure to reply YouTube videos from the memory as I am using 5G internet and I want to minimize my data usage as much as I can.
Again super aggressive memory/CPU spikes, and it was the same thing, only the home page for youtube.com and it was inactive tab and no other tab was sharing the process. it is only one inactive tab for the home page youtube.com and only one process. see Screenshot 2024-12-11 071708.jpg
this again using ff beta 8
|
||
Comment 7•2 months ago
|
||
I need a few things to dig into this bug:
-
It would be nice if you could attach your about:support information so we can look into your hardware configuration.
-
If you can go to profiler.firefox.com and enable the firefox profiler. Then get a profile of Firefox running under this scenario you would like us to investigate while using the 'Graphics' Settings preset. That profile is necessary to debug this in detail.
Thanks.
:lsalzman Maybe same issue here https://bugzilla.mozilla.org/show_bug.cgi?id=1935456
For privacy issue I can't load a profiler in this machine as it is my work laptop. I will try to do in a vm later
|
Reporter | |
Comment 10•2 months ago
|
||
|
||
Comment 11•2 months ago
|
||
|
|
||
Comment 12•2 months ago
|
||
(In reply to Marius from comment #11)
I can help you with as many profiles as you need, Firefox has been nigh
unusable since 133. Constant UI freezes while using Youtube -- Firefox UI
freezes, not the page itself. Menus, typing in textboxes, everything.I need a few things to dig into this bug:
- It would be nice if you could attach your about:support information so we can look into your hardware configuration.
> > 2) If you can go to profiler.firefox.com and enable the firefox profiler. Then get a profile of Firefox running under this scenario you would like us to investigate while using the 'Graphics' Settings preset. That profile is necessary to debug this in detail. https://share.firefox.dev/49zBb6v
Olli, it seems like something is going on with the cycle collector in this profile eating up a lot of time. Any ideas?
|
|
Reporter | |
Comment 13•2 months ago
|
||
After I changed dom.ipc.processCount.webIsolated to 32, now every tab has its own process I can reduce this issue to YouTube home page, channels pages and YouTube searches. these spikes don't happen with tabs that playing YouTube videos. it is only YouTube home page, channel pages, and YouTube searches.
I always open links, videos, even searches in new tabs. so no nothing was opened before will affect the tab.
The aggressive spikes, happen only with YouTube home page. It will even slow down the UI for FF as others have reported.
|
|
||
Comment 14•2 months ago
|
||
these spikes don't happen with tabs that playing YouTube videos
I can assure you that playing Youtube videos is extremely, EXTREMELY laggy in 133. To the point where even subtitles (DOM elements) freeze from appearing for 3-4 seconds each, while the video itself plays smoothly. Any kind of input is frozen during that period.
|
|
Reporter | |
Comment 15•2 months ago
|
||
:Marius to reproduce you have to open videos in new tabs and make sure it doesn't share the process with other tabs.
I can confirm with 100% certainty these wired spikes don't occur in processes that only play youtube videos
To reproduce these wired spikes in youtube home page. If you open youtube home page in a new tab and leave it no spike will occur, until you refresh the page the spikes will start appearing only with the process for youtube home page. When the spikes become aggressive (se Screenshot 2024-12-11 071708.jpg) it will slow down the UI.
Again these spikes are only happening with youtube home page, channel pages, and youtube searches. it doesn't appear in processes that only play videos.
However, the memory usage in version 133 in the processes that play youtube videos are still much more, almost double the usage of previous versions.
About memory eviction, I don't know as I changed dom.ipc.processCount.webIsolated to 32 so every tab will have its own process and closing the tabs will close the processes assigned, so I can't test anymore.
I can confirm that no issues at all in rumble or other sites that play videos, it is only youtube.
|
|
Reporter | |
Comment 16•2 months ago
|
||
(In reply to Jen1 from comment #15)
Again these spikes are only happening with youtube home page, channel pages, and youtube searches. it doesn't appear in processes that only play videos.
This will only start after refreshing the mentioned pages. Opening the mentioned pages for the first time will not most likely start the spikes.
I am currently using 124b10
|
|
Reporter | |
Comment 17•2 months ago
|
||
(In reply to Jen1 from comment #16)
I am currently using 124b10
using version 134b10.
not sure if this helps. but I couldn't reproduce the issue in the VMware virtual machine. The only thing came to mind is it doesn't enable VGA HW acceleration.
Compositing: WebRender (Software)
I will attach the about:support to check as it is with 100% certainty it is one of the disabled features that is causing the issue
|
|
Reporter | |
Comment 18•2 months ago
|
||
(In reply to Jen1 from comment #17)
not sure if this helps. but I couldn't reproduce the issue in the VMware virtual machine. The only thing came to mind is it doesn't enable VGA HW acceleration.
I take it back, I did reproduce the issue in the VM, I recorded many profiles, it took a while though, please see attched the pic, again it is only youtube.com home page, and still in version 134b10 the memory will not be evicted when closing youtube video tabs.
|
|
Reporter | |
Comment 19•2 months ago
|
||
|
|
Reporter | |
Comment 20•2 months ago
|
||
another update: the reason these spike don't appear on tabs that play youtube videos is because I don't refresh these tabs!
I refreshed a tab that plays youtube video, and the spikes did appear.
So, it is only when you refresh a tab for youtube, what ever is, these spike will start. if you open a tab and leave it without refreshing no spike will appear.
so it is something has to do with refreshing youtube tab.
|
|
Reporter | |
Comment 21•2 months ago
|
||
(In reply to Jen1 from comment #20)
So, it is only when you refresh a tab for youtube, what ever is, these spike will start. if you open a tab and leave it without refreshing no spike will appear.
typo: these spike will NOT start
|
|
Reporter | |
Comment 22•2 months ago
|
||
(In reply to Jen1 from comment #21)
(In reply to Jen1 from comment #20)
So, it is only when you refresh a tab for youtube, what ever is, these spike will start. if you open a tab and leave it without refreshing no spike will appear.
typo: these spike will NOT start
the first comment was correct. the correction is wrong LOL, btw it is 'spikes' not 'spike'
|
||
Comment 23•2 months ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #12)
Olli, it seems like something is going on with the cycle collector in this profile eating up a lot of time. Any ideas?
Youtube itself is known to leak and it has been reported to them recently. But since this bug talks about Youtube homepage leaking, it might have even more issues than what I've found so far.
|
|
Reporter | |
Comment 24•2 months ago
|
||
Tested 134rc1 version 134.0.0.3375 and it seems the first 2 issues are fixed, the memory usage seems to be normal again, and the memory eviction upon closing tabs is working again, however just test for a short time will return in case I encountered these issues again but I think they have been fixed.
The spikes are still happening, it looks like they are more aggressive in my short test, as I said it is only upon refresh, or open link in the same tab which has the same effect as refresh.
|
|
Reporter | |
Comment 25•1 month ago
|
||
No, the first 2 issues has not been fixed in 134rc1. Still more memory are used and sometimes memory is not evicted when closing youtube tab.
But here what I noticed. Using private browsing, most of the time the memory usage for youtube videos is normal.
But when using normal browsing, most of the time the memory usage for youtube videos is much more, almost as double as previous versions.
and the spikes are still there. I guess refreshing or opening youtube links in the same tab will cause firefox to clean old pages, that's when the spikes occur. it maybe cc failed and been tried again and again.
|
||
Comment 26•1 month ago
|
||
Jen1, do you have steps to reproduce that work in FF 133 but not in FF 132? (An easy way to run particular versions is using mozregression)
|
|
Reporter | |
Comment 27•1 month ago
|
||
I did reproduce the issue in version 132! Does this mean that youtube/google did something to you youtube API at the same time frame of releasing version 133?
https://share.firefox.dev/3PmGmNM
https://share.firefox.dev/3BZ0gLS
https://share.firefox.dev/4iWTjeK
How ever I did not encounter this issue before 133, excpet of high memory usage when watching youtube live (https://bugzilla.mozilla.org/show_bug.cgi?id=1931717) but not when wtaching normal videos or youtube home page or channel pages.
|
||
Comment 28•1 month ago
|
||
(In reply to Jen1 from comment #27)
I did reproduce the issue in version 132! Does this mean that youtube/google did something to you youtube API at the same time frame of releasing version 133?
That was our conclusion for bug 1931717, which probably share the same root cause, where we observed out-of-memory crash rates got high for all release channels at the same time. Probably safe to say the same here.
|
|
Reporter | |
Comment 29•1 month ago
|
||
tested with nightly 2025-01-09-18-39-00 version 136.0.0.300 and it is even worse. Much more ram is used and much bigger spikes!
https://share.firefox.dev/408H2vm
https://share.firefox.dev/4j2ni50
https://share.firefox.dev/4jbrUpr
https://share.firefox.dev/402AoXm
I guess in my case it is not the ghost windows!
|
|
||
Comment 30•1 month ago
|
||
(In reply to Jen1 from comment #29)
tested with nightly 2025-01-09-18-39-00 version 136.0.0.300 and it is even worse. Much more ram is used and much bigger spikes!
https://share.firefox.dev/408H2vm
https://share.firefox.dev/4j2ni50
https://share.firefox.dev/4jbrUpr
https://share.firefox.dev/402AoXmI guess in my case it is not the ghost windows!
We can check that. If you click Measure under "Show memory reports", what do you see under window-objects under webIsolated=https://youtube.com?
|
|
||
Comment 31•1 month ago
|
||
tested with nightly 2025-01-09-18-39-00 version
And where do you see this? Seems a bit different from the format in about:support.
|
|
||
Comment 32•1 month ago
|
||
(In reply to Jen1 from comment #29)
I guess in my case it is not the ghost windows!
Thanks. It looks like there's more to fix here.
|
||
Comment 33•1 month ago
•
|
||
(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #31)
tested with nightly 2025-01-09-18-39-00 version
And where do you see this? Seems a bit different from the format in about:support.
The profile indicates the nightly is from the larch project branch, specifically revision https://hg.mozilla.org/projects/larch/rev/5bb967849f4a6c95091cf43720aa69a6ba7e831a that does not have the bug 1939295 fix present. (https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly is a good place to get nightly builds from the main mozilla-central branch.)
|
|
Reporter | |
Comment 34•1 month ago
|
||
tested again with build id 20250109183505 mozilla-central and the issue is fixed.
No more spikes, much less memory is used , and youtube loads much much faster, and the memory is evicted now. WOW
The issue is fixed in my case!!!!!
|
|
||
Comment 35•1 month ago
|
||
Glad to hear that, thank you! We are now uplifting the patch to other channels.
|
||
Comment 36•1 month ago
|
||
Fixed for me in 135.0b3 build on Linux
|
|
Reporter | |
Comment 37•1 month ago
|
||
Fixed in 134.0.1 cause of Bug 1939295, bug will be closed!
Description
•