Bugzilla

(In reply to Kestrel from comment #10)
> Performance profile with 215 tabs showing 1 second of jank attempting to open list before failure:
> https://share.firefox.dev/3Uner34
> 
> May be easier to reproduce in a VM with limited resources.

Thank you, this is helpful. Out of 751 samples in the hang in that profile, 518  (so roughly 2/3) are going on creating/escaping/parsing `data` URIs for images. And in fact, if I'm not misreading the profile (possible!), all of that is exactly _one_ image, not even multiple ones (because I'm seeing time spent sequentially at 1 depth in the frame tree to first add the URI and then load the image).

Do you just have 1 tab in that set of 218 with like a giant data URI as favicon and/or URI, perhaps?

(obviously it'd be nice if we handled that better but it would be nice to confirm if that is actually the problem)

Creating the DOM for the 218 rows is only taking about 100ms (judging by some preference read markers for which I'll shortly file another bug...) which although not super fast doesn't look like it'd cause the issues here.

(In reply to Kestrel from comment #10)
> Performance profile with 215 tabs showing 1 second of jank attempting to open list before failure:
> https://share.firefox.dev/3Uner34
> 
> May be easier to reproduce in a VM with limited resources.

Thank you, this is helpful. Out of 751 samples in the hang in that profile, 518  (so roughly 2/3) are going on creating/escaping/parsing `data` URIs for images. And in fact, if I'm not misreading the profile (possible!), all of that is exactly _one_ image, not even multiple ones (because I'm seeing time spent sequentially at 1 depth in the frame tree to first add the URI and then load the image).

Do you just have 1 tab in that set of 215 with like a giant data URI as favicon and/or URI, perhaps?

(obviously it'd be nice if we handled that better but it would be nice to confirm if that is actually the problem)

Creating the DOM for the 215 rows is only taking about 100ms (judging by some preference read markers for which I'll shortly file another bug...) which although not super fast doesn't look like it'd cause the issues here.