2012370 - Massive memory leak (2GiB -> 10GiB usage) from a single Google search with CanvasBlocker

Status: RESOLVED DUPLICATE of bug 2011064

(Firefox :: Performance, defect)

Description

[J0w03L]

Attachment: memory-report.json.gz

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

Steps to reproduce:

I opened Firefox Developer Edition, created a tab at about:memory, opened a new one, went to https://google.com and searched "test 123".

I also scrolled all the way down and back up, and then went back to the first tab to generate a memory report, but this isn't needed to repro the bug.

This is a freshly updated Firefox Developer Edition 148.0b6, 64-bit on Arch Linux. I was hoping that the update would fix this bug, as I assumed it would be noticed pretty quickly, but it seems maybe this is more specific to my use case? Either way, I've been dealing with it for a few weeks now...

Actual results:

My RAM usage spiked from ~2000MiB to over 10000MiB for a few moments, before settling back down slightly to where I sit here typing this, ~6000MiB.

During the spike, page rendering is completely halted (scrolling down, its just blank), and if I stay on the page, I get the warning that the page is slowing me down.

This does not happen on all websites, but it does happen on Google and YouTube (Though for YouTube, it's mostly just the homepage...)

If I use another search engine (for example, DuckDuckGo, it is not an issue.)

The issue appears to only occur if I have Ublock Origin enabled, so maybe Google is pulling some weird stuff...

Expected results:

Nowhere near this amount of memory usage.

Comment 1

[J0w03L]

Oh, and because I noticed it last second, here's my UA:

Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0

Comment 2

[J0w03L]

Also, scratch that point about ublock origin being involved, I thought that was the case in previous testing, but after restarting my browser and trying it again just to be sure, having it disabled does not change things.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 4

[J0w03L]

Changing this to Performance as it feels more appropriate.

Comment 5

[J0w03L]

Further details as per bug writing guidelines; Here's a bit more info:

• The bug does not occur in at least Firefox 141; but it's a fair bit more recent than that. I'm just basing that from a second, more outdated system I have. The system I'm having this issue on gets updated much more often, so I would say this had to have been introduced after Firefox 145; this is undoubtedly a bug introduced this year (unless I have just only now managed to meet whatever criteria for it). I would update my other system to test if it happens there, but I'd like to avoid crippling my browser on there too if possible.
• Build ID: 20260123181701
• Built from: https://hg.mozilla.org/releases/mozilla-beta/rev/42f9c56559ad99f08140eb8537249584adfcda4e
• OS: Linux 6.18.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 18 Jan 2026 00:34:07 +0000

Comment 6

[Simona Badau, Desktop QA]

I could not reproduce the memory issue on Firefox Developer 148.0b8 on Ubuntu 24.04.

@mconley, if time allows, could you please take a look at the attached memory report?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

I can see from the report that two of the content processes are holding a few GB of memory, but the report is quite anonymized, so there's not a whole lot more I can tell, beyond the fact that (I think) some window objects are being held alive by JS?

Maybe mccr8 can see more than I can - what do you think, mccr8?

Comment 8

[J0w03L]

Been busy with work and stuff, woulda said earlier today, but disabling CanvasBlocker fixes the issue. The same latest version of CanvasBlocker doesn't do this on my machine with the older Firefox though, so I'm not entirely sure whose side the problem is on here...

Comment 9

[:Gijs (he/him)]

Does this reproduce on a clean Firefox profile on the machine where you're seeing this, with only canvasblocker installed? If so, perhaps you'd feel comfortable sharing an un-anonymized performance profile (using https://profiler.firefox.com/ , with memory profiling turned on) from that otherwise vanilla profile? I did notice there were complaints about youtube memory leaks with this add-on noted in the reviews for CanvasBlocker a few months ago as well. As you say, there may still be something Firefox is doing wrong, but without some more details on what is going wrong in this case I suspect it'd be difficult for either the CanvasBlocker dev or us to address. Thank you!

Comment 10

[Andrew McCreight [:mccr8]]

(In reply to J0w03L from comment #8)

Been busy with work and stuff, woulda said earlier today, but disabling CanvasBlocker fixes the issue. The same latest version of CanvasBlocker doesn't do this on my machine with the older Firefox though, so I'm not entirely sure whose side the problem is on here...

Thank you for the update! I'm glad you figured this out and I'm sorry we weren't much help. A colleague dug into another report of CanvasBlocker causing severe leaks in a way that started recently so I'm going to dupe this issue over there (bug 2011064).