1451517 - Really high CPU and memory usage on zerohedge.com due to ads

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P3)

Description

[Andrew McCreight [:mccr8]]

If you open zerohedge.com in Firefox, it uses a ton of CPU. My laptop gets hot and my battery seemed to be going down quickly. The site also uses a lot of CPU in Chrome, but not nearly as much. In Chrome, there's a message about them blocking a script, so maybe that saves them?

Comment 1

[Andrew McCreight [:mccr8]]

This was originally reported by bht237 in bug 1428239 comment 25:

(In reply to bht237 from comment #25)
> Hi, I hope I can make a contribution.
> 
> 1) I confirm a real, extreme memory leak that occurs within less of an hour. 
> 2) I can confirm that this happens with 30 tabs open or less
> 3) I am using Windows 7
> 4) I have a suspicion that the memory leak is caused by some pages and not
> others.
> 5) One suspect is zerohedge.com
> 6) After closing tabs of the suspect site, memory is not freed.
> 7) After closing tabs of the suspect site, and re-starting the browser via
> Developer Toolbar (Shift+F2; Firefox menu button or Tools > Web Developer)
> then "restart" in the command line and [Enter], memory usage is back to
> normal in the vicinity of 250Mb per instance
> 8) I don't have an issue with the number of firefox processes running. The
> issue is with a single process consuming 3GB which makes system recovery
> extremely difficult. In this case, the browser crashes on re-start but
> recovers after that.
> 
> So I would kindly suggest to the developer working on this issue to try on a
> Windows computer any number of tabs with different subject pages (not only
> the home page) of zerohedge.com and leave the browser open for a few hours.
> It might not be necessary to open 30 such tabs, I have never needed to open
> more than 5 to get the memory leak, but in most cases I had between 10 and
> 30 tabs open.
> 
> I have more than 20 years experience with FireFox, Netscape etc. and have
> filed hundreds of Mozilla bugs and I can confirm that this is really
> serious. If it is not fixed, we might find that people will simply dump this
> browser. They will never reach out and find ways to escalate this as
> required.

Comment 2

[bht237]

I reported zerohedge.com as causing a memory leak in FireFox, see bug 1428239

Hope this will help improve FireFox although I do not see the high CPU usage primarily. Perhaps the CPU usage is because of the memory problem or both. I don't know. I can confirm though that FireFox whether it is the culprit or not, becomes a security risk because it can be hijacked by a site like this in a way that it takes my PC down if I don't be careful. At the minimum it is awful.

Comment 3

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Since this is zerohedge.com, do we know if there are 'mining' scripts running that are not caught by content blockers and consuming CPU?

Comment 4

[Andrew McCreight [:mccr8]]

I have no idea, sorry.

Comment 6

[Andrew McCreight [:mccr8]]

If the other one is going to be about memory, then this doesn't need the MemShrink tag. I'd guess that the reasons for both are the same but I haven't investigated.

Comment 7

[Ted Campbell [:tcampbell]]

With Tracking Protection on, this is fine. Without, the page continuously spams ad loads and profile seems pretty to be continuously updating layout and re-rendering. I don't see any specific SpiderMonkey concerns. Webpage seems to do terrible things in it's ad code.

Comment 9

[Andrew McCreight [:mccr8]]

Thanks for taking a look. I'm not sure what we can really do about this in Firefox.

Comment 10

[bht237]

The main issue from my perspective is that after closing all zerohedge.com tabs, memory is not released. Whatever the ad code is doing, as bad as it might be CPU and memory wise, Firefox should be recovering after closing the tabs. As I wrote in duplicate bug 1455161

1) Go to zerohedge.com
2) Open one of the main links on that page in a new tab
3) Wait.

Memory grows very quickly within a few minutes until all available RAM is consumed, so don't wait THAT long

4) After closing tabs of the site, memory is not freed.

5) Alternatively, it is possible to kill the memory consuming process in task manager. The offending tab is crashed, and browsing can continue.

Comment 11

[Marion Daly [:mdaly]]

(In reply to Ted Campbell [:tcampbell] from comment #7)
> With Tracking Protection on, this is fine. Without, the page continuously
> spams ad loads and profile seems pretty to be continuously updating layout
> and re-rendering. I don't see any specific SpiderMonkey concerns. Webpage
> seems to do terrible things in it's ad code.

What about the issue reported by bht237 with the memory not being released after leaving the tab? Please verify.

Comment 12

[bht237]

It wasn't really a good idea to combine / dup these issues CPU and memory even though they are caused by the same site. Cognitive bias all over the place.

Comment 13

[Andrew McCreight [:mccr8]]

Ah, right, I forgot about the part where the page wasn't going away. I guess I'll undupe this.

Comment 14

[Andrew McCreight [:mccr8]]

Ehsan looked at this a little and made a profile: https://perfht.ml/2HRU4nj

When he looked at it, it sounded like a lot of time was being spent in a Flash ad that was being autotranslated by Google into canvas. I'm not sure if that will end up falling under JS or maybe under DOM or graphics. That may also be a different issue than what other people have seen.

Comment 15

[(no longer active)]

My guess would be 2D canvas, but I didn't look too closely.

Comment 16

[Nicolas B. Pierron [:nbp] {away}]

Looking at the devtools profiler, it seems to me that event are repeated in the following order:

- Some "timeupdate" (?) event trigger the "updateContent" function call, under [1] which it does an innerHTML.
- A bunch of setTimeout handler created in [2] and wakes up ~40 other handlers.
- Followed by some "Recalculate style" and "Layout".

At the same time, I also see the following error messages repeated in the console:

> [Child 24330, MediaPlayback #2] WARNING: Decoder=7f5413804400 state=DECODING_METADATA Decode metadata failed, shutting down decoder: file /builds/worker/workspace/build/src/dom/media/MediaDecoderStateMachine.cpp, line 372
> [Child 24330, MediaPlayback #2] WARNING: Decoder=7f5413804400 Decode error: NS_ERROR_DOM_MEDIA_DEMUXER_ERR (0x806e000c) - virtual RefPtr<mozilla::MozPromise<mozilla::MediaResult, mozilla::MediaResult, true> > mozilla::MP4Demuxer::Init(): No MP4 audio () or video () tracks: file /builds/worker/workspace/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3411

I cannot tell from this analysis if this is a website issue only, but there are definitely issues with a video ad.

[1] https://c5x8i7c7.ssl.hwcdn.net/vplayer-parallel/20180508_1250/videojs/video.min.js
    Taken from https://github.com/videojs/video.js (based on the file header)
[2] https://ecdn.firstimpression.io/fi_client.js

Comment 17

[Daniel Holbert [:dholbert]]

We're just looking at this in qf triage (per [qf] tag added earlier today) -- looks like the profile we've got here in comment 14 is 4 months old, and also nothing's jumping out as the obvious culprit, at first glance.

Andrew, would you mind seeing if you can still repro, and (if so) making a new profile? (and we'll take a look in next week's qf triage)  Let me know if you need any help with the profiler.

Comment 18

[Andrew McCreight [:mccr8]]

I'm not going to be able to get to that for a few weeks but I guess I'll leave it in my needinfo queue.

Comment 19

[Daniel Holbert [:dholbert]]

OK - never mind, I just tried loading the site -- and I do see that even after it's fully loaded, it's got constant ~120-150% CPU usage reported by "top", when it's in a foreground tab.

Here's a profile after load has finished, of just the "static" fully-loaded site experience (with 120-150% cpu reported in 'top'):  https://perfht.ml/2LgTrEZ

It's not always that bad, though -- on another load, the steady-state is only ~30-50% cpu usage.

>  In Chrome, there's a message about them blocking a script, so maybe that saves them?
I don't actually see any such message from Chrome (might be a version-specific thing though -- I'm using "Chrome 70.0.3528.4 (Official Build) dev (64-bit)" on Linux.

And for the few times I tried in Chrome, I was seeing highish CPU usage for this site's "steady state" in Chrome, though never quite as bad as the worst results that I observed in Firefox.  (worst I saw in Chrome was it bouncing between 80-120% CPU)