[Bug]: Periodic UI hang on profile with large numberof tabs

[nike4613]

Pre-Submission Checklist

• I have checked the existing/closed issues to ensure this issue has not already been reported.
• I am using the latest supported version of the browser.
• I have tried disabling all browser extensions/add-ons to rule out interference from these.
• I have tried clearing the browser cache and cookies.
• I have checked with a new profile and the issue still occurs.
• I have provided detailed step-by-step instructions on how to reproduce the issue.
• I have included relevant screenshots or console outputs.
• I have checked that this problem is not occurring in the latest version of Firefox ESR.
• This issue is specific to this browser and does not occur in other browsers.

Bug Summary

Starting around 11.17.6, I began to notice that the UI would periodically hang for multiple seconds, with no discernible cause.

It seems to only happen when I have a website sidebar panel configured (not even necessarily open).
It only happens on my very large profile, not my much smaller second profile.

I have a profiler trace showing it happen.

Reproduction Steps

1. Open a profile with ~8 windows with around 100 tabs each
2. Create a side panel, but don't open it
3. Wait a while. It doesn't happen immediately, but will happen eventually.

Expected Behavior

No UI hangs.

Actual Behavior

Multiple second UI hangs, rendering the browser entirely unusable for that period.

Screenshots

It seems to be spending its time in mozilla::dom::ContentParent::LaunchSubprocessResolve, specifically in mozilla::dom::BlobURLProtocolHandler::ForEachBlobURL() and mozilla::dom::PContentParent::SendInitBlobURLs(), where it seems to be enumerating a very large linked list repeatedly as it tries to serialize the blob URLs.

I speculate that this is triggered by something relating to the sidebar, since the issue doesn't appear to happen without any sidebar views present scratch that, it seems to happen anyway. I also see the main process memory usage grow massively when this happens (most recently to ~20GB before I had to kill it).

I don't think the profiler can track task/promise causality, so I don't know how to get anything more specific without a very intrusive full debugger.

Browser Version

11.19.1 (Firefox 128.4.0)

Operating System

Windows 10 22H2

Additional Context

Here is the profile (for https://profiler.firefox.com):

Floorp 2024-10-13 03.35 profile.json.gz

(Note that I'm currently running a local build of 11.19.1 so I have symbols.)

[nike4613]

An update on this: I've broken into BlobURLProtocolHandler::ForEachBlobURL, and I'm seeing a lot of seemingly bogus blobs, of the general form blob:null/<guid>. The backing hashtablee has 40402 entries in it. Next, I'm going to see if I can get a breakpoint when one of these blobs is added.

[nike4613]

Alright, I got it nice and quickly. It looks like it's happening as a result of a timer event, created through a call to URL.createObjectURL in a promise constructor. Working on getting an actually useful JS stack still.

[nike4613]

After a great deal of pain, I now have a JS stack:

(order is top of stack to bottom of stack; most recent frame at the top)

chrome://floorp/content/browser-favicon-color.mjs:100
chrome://floorp/content/browser-favicon-color.mjs:44
chrome://floorp/content/browser-favicon-color.mjs:142
chrome://floorp/content/browser-favicon-color.mjs:194

(The first line number seems to be just a bit off, but the others seem more or less accurate)

For those wondering how

Attach to the main process in WinDbg, then after you've broken with JS frames on stack:

0:000> dx sizeof(js::FrameIter)
0:000> .dvalloc <value of sizeof(js::FrameIter)>
// result of above allocation will now be called pIter
0:000> x xul!js::FrameIter::FrameIter
// pick the address of the DebuggerEvalOption overload above, that address will be called pCtor
0:000> x xul!js::FrameIter::operator++
// the address that gives will be called pNext

// Now, construct: (note that cx_ is a JSContext*, which can be found in any JS-interop frame)
0:000> .call pCtor(pIter, cx_, 1); ~.g
// the iterator is now set up for the first frame

// to get source info for a frame, use this:
0:000> .call js::FrameIter::filename(pIter); ~.g; .call js::FrameIter::computeLine(pIter, 0); ~.g

// to advance the iterator, use this:
0:000> .call pNext(pIter); ~.g; dx ((xul!js::FrameIter*)pIter)->data_.state_
// IF THAT FINAL dx COMMAND SAYS DONE, DO NOT CONTINUE ITERATING!

// then cleanup
0:000> .call js::FrameIter::~FrameIter(pIter); ~.g
0:000> .dvfree pIter <value of sizeof(js::FrameIter)>

[nike4613]

Per the docs on URL.createObjectURL:

The URL lifetime is tied to the document in the window on which it was created. The new object URL represents the specified File object or Blob object.

To release an object URL, call revokeObjectURL().

I think adding a revokeObjectURL call once the image is done being used should fix the issue. I'll make the issue locally and test.

[creeper-0910]

Thank you so much for the detailed explanation and the steps involved!
We currently looking into a high load issue regarding browser-favicon-color.mjs.
Your information will help me solve this problem faster, thank you!