1646174 - [Meta] Blob: on GamesRadar consumes entire cpu core when the active tab.

Status: NEW

(Core :: Performance, defect, P3)

Description

[Danial Horton]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Waterfox/56.3

Steps to reproduce:

Navigated to Gamesradar.com or any article on the gamesradar site.

Watch the process list in task manager.

Actual results:

A content process began consuming cpu indefinitely, memory may consume several gigabytes if left open for a period of time, particularly on any of the articles embedding gifycat players.

Expected results:

It definitely shouldn't eternally chew a cpu core,

I have confirmed this across several firefox versions (and waterfox) and fresh profiles, and narrowed it down to the site being allowed to load a Blob:

Comment 1

[Danial Horton]

Attachment: Profile json of the site just sitting consuming cpu

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Danial Horton]

I doubt it since the issue manifests regardless of the use of webrender.

Comment 4

[Danial Horton]

There is no webrender available in a VM, and the sanity test disable pref is set anyway so its unrelated to web render.

To note, this occurs on waterfox classic as well which doesn't have webrender enabled, but the testing has been done on firefox 72 and 77 as well with these prefs on real hardware so its got nothing to do with it

Firefox is chewing a cpu regardless of the presence of support for webrender.

Comment 5

[Danial Horton]

The offending blob is loaded from https://quantcast.mgr.consensu.org/choice/uer8ZPXHG8WDU/www.gamesradar.com/choice.js?timestamp=

Comment 6

[Emilio Cobos Álvarez (:emilio)]

There's a bunch of stuff going on in that profile, including one tracker script checking window dimensions and other stuff in an interval. There's still a fair amount of time spent in the setInterval machinery itself...

I wonder, is this similarly bad on Nightly? I think some timer improvements landed in 78.

But yeah, clearly nothing webrender specific there.

Comment 7

[Danial Horton]

Hi Emilio, I have blocked the specific quantcast blob rather than all of them as i had been to mitigate temporarily and the issue is gone,

it looks like it is supposed to make a GPDR cookie banner appear, but never does, it may be an issue in the websites implementation of this script, but i haven't come across other sites using quantcast to make a firm conclusion on that.

I'm afraid nightly is no better off here.

Comment 8

[Danial Horton]

Attachment: Nightly profile of the page

Comment 9

[Markus Stange [:mstange]]

I found two issues so far:

1. The site is using setInterval(..., 0) and we don't throttle it (bug 1646799).
2. In Nightly, SavedStack capturing is responsible for most of the memory usage (bug 1646792).

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Markus Stange [:mstange] from comment #9)

I found two issues so far:

1. The site is using setTimeout(..., 0) and we don't throttle it (bug 1646799).

I guess you mean setInterval

Comment 11

[Markus Stange [:mstange]]

er, yes, fixed the comment

Comment 12

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #9)

2. In Nightly, SavedStack capturing is responsible for most of the memory usage (bug 1646792).

This turned out to be false. The memory is consumed by other JS objects but I'm not sure how. The memory devtools might help answer that question.

Comment 13

[Markus Stange [:mstange]]

I've grabbed a few snapshots with the memory devtools and most of the memory seems to be PromiseReaction and Function objects. They're rooted in some mCallback. I don't know what that means - maybe the page is never canceling its setIntervals, and just stacking up more and more of them?