407370 - High CPU usage on a site with lots of embedded YouTube videos

Status: RESOLVED DUPLICATE of bug 392394

(Core :: General, defect, P3)

Description

[laniksj]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre

When visiting a forum/site which has lots of YouTube videos posted the CPU spikes as high as 100% and makes the browser unusable until you navigate away from that page.  The memory utilization also goes up to over 200+ MB.  This makes playing videos impossible.

Reproducible: Always

Steps to Reproduce:
1. Visit PoC: http://www.lanik.us/misc/ff-flash-test.html
2. Observe memory and cpu usage
Actual Results:  
The memory/cpu usage on the browser goes up and makes watching videos impossible.

Expected Results:  
You should be able to watch videos with no problems.

I've tested this with Fx 2.0.0.11 also and it has the same issues.  IE on the other hand has no problems.

Comment 1

[laniksj]

Attachment: Fx CPU and Memory usage

Comment 2

[laniksj]

More info can be found also in this forum thread: http://www.dslreports.com/forum/r19578329-FireFox-High-CPU-Usage-On-Certain-Web-Pages

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm seeing this, too. It's a pretty odd use case, though, and doesn't seem to affect normal browsing habits.

This will remain as wanted until it's set as blocking 1.8.1.12.

Johnny/Tony, can you look into this?

Comment 4

[fat ness]

http://www.lanik.us/misc/ff-flash-test.html
I experience very high CPU usage on that page.

FF 2.0.0.11
Adobe Flash 9.0.28.0
XP Pro SP2

Comment 5

[La Luna]

http://www.lanik.us/misc/ff-flash-test.html

Fx utilization climbs to between 25-30% when in focus, back to zero when not focused.

•AMD Athlon64 3800+ Newcastle Core CPU 2.4GHz
•3GB RAM
•Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
•Adobe Flash 9.0.115.0
•XP Pro SP2

Comment 6

[Greg]

Same results as Comment #1

Fx v2.0.0.11

3.2GHz P4, 1gb memory
Flash v9.0.115.0

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Are any of the reports of slowness in this bug recent regressions? I think it would be best to keep the 1.8 branch discussions separate from the trunk discussions, unless there's reason to believe the same change has caused both...

Comment 8

[laniksj]

Gavin,

I can't tell when this started I just noticed this by accident recently.  Based on https://bugzilla.mozilla.org/show_bug.cgi?id=407370#c3 this problem existed for a while now.  I'll do some branch/trunk testing to see if I can narrow it down a little bit.  To be honest I don't even know where to start at this point.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

For this bug report to be useful, it needs to stay focused on the recent behavior change. There have been a lot of historic "flash uses CPU" bugs, and this turning into the dumping ground for anyone who notices high CPU usage in any version quickly makes it rather useless for isolating and fixing actual bugs. If there was a recent change it should be possible to look through recent "trunk" builds at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and narrow down a regression range.

Comment 10

[fat ness]

"Are any of the reports of slowness in this bug recent regressions?"

To the best of my knowledge: I used 2.0.0.10 so briefly that I do not know if it affected that build. It affects 2.0.0.11. It did not affect anything 2.0.0.9 or earlier. 

Comment 11

[:Gavin Sharp [email: [e-mail]]]

The original report (comment 0) was filed against a trunk build, and you're reporting problems with a branch build. One possibility is that a patch landed on both the trunk and the branch that could have caused this. Another is that maybe Youtube's changed something that's causing high CPU usage across all Firefox builds. We need to figure out which of those is true in this case - best way to do that would be to test nightly builds from either the trunk or branch using the link from my previous comment, and try to find a 1-day range where the regression took place.

Comment 12

[laniksj]

I'll do some nightly testing Gavin.  I'll start with Trunk builds and see what I end up with I'll keep you posted on this bug.  Thanks.

Comment 13

[Steve Snyder]

FWIW:

SeaMonkey v1.1.7 on Win2K/SP4, Pentium4/2.4GHz, 1024MB RAM: ~16% CPU utilization

Firefox v2.0.0.11 on WinXP/SP2, Pentium4/1.8Ghz, 1024MB RAM: 98% CPU utilization

I was all set to make a smart comment about SeaMonkey's obvious superiority over Firefox.  Then I scrolled to the botton of the page, then back to the top.  Now SM is running with ~98% CPU utilization.

Re-ran SM, and loaded the test page.  CPU use is again ~16% after initial page load.  After scrolling down to the bottom (mouse held down on thumb) SM is pegging the CPU.

This is with Flash version 9.0.115.  Flash itself does not appear to be using CPU time while SM/FF is pegged.

Comment 14

[Damon Sicore (:damons)]

+'ing this so that we make sure that we investigate this issue.  We might be able to find specifics here on perf.

Comment 15

[Cédric]

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
OS : Windows XP SP2 Profesionnal
I have the same problem on the version 3.0b2 like on this page : http://www.raphaelgilmas.com/lagazettedubuzz/cinma/index.html

Unlike reported before CPU usage is always at 100% with or without focus (tab or firefox). It back to 0% when the tab is closed.

Comment 16

[Daniel Veditz [:dveditz]]

Not blocking branch security releases, but if we find this is a Firefox bug and get a tested trunk fix we can look at it (request approval on a reviewed branch patch).

Comment 17

[Bob Clary [:bc] (inactive)]

http://www.lanik.us/misc/ff-flash-test.html is 404 now. http://www.raphaelgilmas.com/lagazettedubuzz/cinma/index.html still pegs cpu on linux with a recent trunk build and flash 9.0.115, but also did so with 2005-01 builds.

Any reason not to dupe this against bug 392394 and to make 392394 a blocker?