Firefox eats way too many CPU cycles with certain pages

Bug #16465 reported by Rimas Kudelis on 2005-04-26
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
firefox (Ubuntu)
firefox-3.5 (Ubuntu)

Bug Description

Firefox becomes very unstable and eats lots of CPU when opening sites with DHTML scrolling message (javascript marquee).

Mozilla bug tracker has a few testcases attached to the upstream bug ( ), such as this one: .

The bug does not involve any use of Flash or other plugins, so this bug is not the same as bug 14911.

Rimas Kudelis (rq) wrote :

rq@sugar:~ $ apt-cache policy mozilla-firefox
  Installed: 1.0.2-0ubuntu5

Daniel Robitaille (robitaille) wrote :

It seems that this web page is coded with only javascript code in a
browser-neutral approach, no plugins used that I can see (no flash, no java,
etc). So it's probably not an issue with plugins, and is very likely not
related to #8589.

I haven't been able to experience any unstability while visiting that URL. But
it does eats CPU: just by having Firefox sitting on that URL and the load
average on my machine was continously oscillating between 0.65 and 0.75. But I
don't think it's a problem with Firefox itself but because of the way the page
was coded: to have that scrolling banner on the left-hand side of that web page
continously scroll using javascript directives, Firefox has to contionsly load a
new javascript function every 50 millisecond, thus the continous CPU load.

Rimas Kudelis (rq) wrote :

I just opened the page. Loads began to rise continously, until they reached
something like this:
load average: 1.30, 0.75, 0.47
Plus, the CPU usage bar, which was usually at 5-15%, grew up to 100% when i
pressed Enter after typing the URL (OK, that's normal), and it didn't fall down
until i pressed Ctrl+W (that isn't normal). Also, after switching workspaces,
Firefox didn't even refresh its view until I closed the active tab in which the
case URL was loaded.
yesterday, I checked the same page on Windows' build of Firefox. after the page
was loaded, my CPU usage graph values grew up by ten per cent, and floated there
instead of growing continously.

Jorge Castro (jorge) wrote :

I see this too in breezy, confirming.

Ian Jackson (ijackson) wrote :

This is the same as the upstream bug:
which has been there for some time.

The root cause of the problem seems to be (1) use of an algorithm which is more
cpu-intensive than the (pretty evil) page designers expect (which I assume means
more cpu-intensive than common versions of IE) combined with (2) a failure to
limit the amount of work done pursuant to a page's javascript (which turns it
from a `doesn't render' into a `makes program difficult/impossible to use').

In my tests firefox sometimes locked up completely but usually it was able to
respond to incoming UI events sufficiently well to get off the offending page.

Ian Jackson (ijackson) wrote :

*** Bug 19373 has been marked as a duplicate of this bug. ***

Changed in firefox:
status: Unconfirmed → Confirmed
Rimas Kudelis (rq) wrote :

Just a note: the URL of the page has been changed. It might also be changed in the future, in that case i'll update it here too.

Berti (bertrand-haut-gmail) wrote :

Maybe the same problem here ( ) :

I've the same problem, launching firefox on some page ( ). The computer slows down, Here is the result of top :
Tasks: 132 total, 2 running, 130 sleeping, 0 stopped, 0 zombie
Cpu(s): 90.0% us, 0.3% sy, 0.0% ni, 9.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1028276k total, 844096k used, 184180k free, 36084k buffers
Swap: 1461904k total, 0k used, 1461904k free, 373752k cached

 5352 root 19 0 204m 26m 4748 R 85.2 2.7 2:57.95 Xorg
 7240 berti 16 0 254m 49m 25m S 2.7 4.9 0:02.95 firefox-bin
 5765 berti 15 0 142m 40m 20m S 2.0 4.0 0:59.21 konqueror

Killing firefox and everything gets back immediatly to the normal situation. I'm using an ati card with the open-source "ati" driver. This is an up-to-date dapper on a AMD64 machine.

Jonathan Carter (jonathan) wrote :

There was a bug up to firefox where a page that refreshes itself a few times could cause firefox to eat a huge amount of RAM and CPU time. Does this bug persist with, which is included with Dapper?

Berti (bertrand-haut-gmail) wrote :

Personally I can't say. For me the only site which presented this problem ( has completly changed.

But I've not met this bug since some times.

Rimas Kudelis (rq) wrote :

Well, here's what I have in "top" when I open in Firefox (which is now, btw):
 5169 rq 25 0 127m 50m 17m R 71.3 13.4 9:53.58 firefox-bin

Here's what I have when I close the tab:
 5169 rq 15 0 128m 51m 18m S 0.3 13.6 10:48.83 firefox-bin

As you can see, CPU usage falls drastically (from 50-80% to 0-10%). I think the bug is unfortunately still present...

jetpeach (jetster) wrote :

CPU usage for me on the above page also shoots to above 65%, when the tab is closed it drops to 5%. I attached

Open the same page in Konqueror, it's usage stays <10% and the scrolling part of the page still renders properly.

Also, I tested this with my Edgy Eft running Bon Echo beta2 (Firefox2), to see if it is fixed in that version. It was not.

Somebody should possibly see if this also happens on windows? And if it happens in the next Gecko tree after 1.8.1? what is it, 1.9 for Firefox 3?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060731 Ubuntu/dapper-security Firefox/

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b2) Gecko/20060601 Mozilla Gecko Firefox/ (Ubuntu-edgy)

Ian Jackson (ijackson) on 2006-09-19
Changed in firefox:
assignee: ijackson → nobody
Chris Wagner (chris-wagner) wrote :

I'm on the finished Edgy and the problem does not seem to be too bad. On my machine, that site ( causes Firefox to use around 20% to 30% CPU. This may not be ideal, but my system is still quite usable. Konqueror does not have near the spike in CPU usage when visiting the same page. Does anyone else find the problem to have been mitigated with Edgy final?

description: updated
pirast (pirast) wrote :

For me, it is very bad on a Feisty installation, i.e. on

The virus ticker there causes my Xorg to have an usage of ~40 percent. Thus, I can't really use my computer. For example, my mouse cursor is jerking after some time.

Rimas Kudelis (rq) on 2006-12-07
description: updated
Rimas Kudelis (rq) wrote :

Chris: 20% to 30% is still way too much for for just a scrolling text message.

Martin: confirm. When visiting that AVG site, CPU usage of Firefox rises to about 20%, and Xorg starts eating about 80% to 100% (!!!)...

Changed in firefox:
status: Unknown → Confirmed

On Thu, 2006-12-07 at 05:21 +0000, Rimas Kudelis wrote:
> Chris: 20% to 30% is still way too much for for just a scrolling text
> message.

You're probably right about that - but, has the problem gotten any
better at all?

Rimas Kudelis (rq) wrote :

Chris Wagner wrote:
> On Thu, 2006-12-07 at 05:21 +0000, Rimas Kudelis wrote:
>> Chris: 20% to 30% is still way too much for for just a scrolling text
>> message.
> You're probably right about that - but, has the problem gotten any
> better at all?

Not really. Fx still eats ~46% of my CPU if I visit the testcase website.

David Farning (dfarning) on 2006-12-31
Changed in firefox:
assignee: nobody → mozillabugs

I now get the same thing I have attached the crash report.

David Farning (dfarning) on 2007-02-24
Changed in firefox:
assignee: mozillateam → mozilla-bugs
TomasHnyk (sup) wrote :

works just fine for me as of Feisty final,is this still an issue?

Rimas Kudelis (rq) wrote :

TomasHnyk: You're right. At least with the website mentioned in the initial bug report, CPU usage no longer rises that much (still it does rise from 6 to 30 percent, looking at the output of `top`).

Rimas Kudelis (rq) wrote :

Hm, seems like nothing has changed much since Edgy.

TomasHnyk (sup) wrote :

the site in original bugreport work ok now, but for example this one taken from upstream bug report is still taking 100%, so it is still an issue.

Adam Niedling (krychek) wrote : eats about 50-70% cpu time for me but yes this is a valid bug.

Rimas Kudelis (rq) wrote :

The webpage used in the original report has been fully redone since reporting, and is no longer publicly available. That's why you see it as working OK.

I have removed the links pointing to it, and added links to the upstream bug and testcases instead.

description: updated
pirast (pirast) wrote :

I have tried it using Firefox 3 and it still takes lots of CPU cycles:

2622 martin 20 0 234m 103m 22m R 88.1 10.3 2:00.91 firefox-bin

BUT: Firefox remains *very* responsive and my load average is 0.98 which is good (sempron 3000+)

Joel (yoeldk) wrote :

i can confirm this bug on kubuntu 8.04.
some websites causes firefox (either 2.0 or 3 beta) and xorg to use massive amount of CPU.
(firefox CPU usage may go beyond 90% on these sites, and my box is Pentium D 3.2Ghz with 2 GB RAM).

examples for these sites:

Igor Levicki (levicki-i) wrote :

For me this page gives constant 50% CPU load and rising memory usage for Firefox 3 release version under Windows XP x64 SP2:

I have dual-core CPU and Windows scheduler seems to be bouncing the thread around so that my whole system becomes unresponsible, not just Firefox. On some pages I have observed Firefox process eating 700+ MB of RAM (and increasing) when this high CPU load happens.

If I lock the process to one of the cores, then the system responsiveness improves, but Firefox is still sluggish.

When I check with Process Explorer, the IP of a thread consuming CPU time is inside js3250.dll address space or sometimes in xul.dll. When it is inside of js3250.dll stack trace also includes xul.dll.

On one of the pages I have narrowed the problem down to the -- if I block * using adblock, and reload the page the problem disappears.

I believe it is a JavaScript related bug.

Igor Levicki (levicki-i) wrote :

Oh and I forgot the most important thing -- disabling JavaScript in options brings CPU usage immediately down to 0%.

krom (krom) wrote :

problem disappeared for me after installing latest nvidia drivers (180.06)

apepin (andre-pepin) wrote :

Just to add another site example for this bug, if this can be of any help.

Adam Niedling (krychek) wrote :

The site mentioned by apepin gives me 20-30% CPU usage. It's caused by the moving text. When I move my mouse over it, it stops and CPU usage goes down to 4-5%.

Adam Niedling (krychek) wrote :

This is not a Firefox only issue. I just tested it with Vista and Internet Explorer 7 and the issue is the same. It's also the same with Firefox under Vista. That scrolling text is a bad thing.

Sameer Aslam (samalpha) on 2009-10-04
Changed in firefox (Ubuntu):
assignee: Mozilla Bugs (mozilla-bugs) → Sameer Aslam (samalpha)
John Vivirito (gnomefreak) wrote :

This will most likely land in firefox-3.6
Please dont assign yourself to bugs you have no plan on fixing. we will release this fix when it is fixed.

Changed in firefox (Ubuntu):
status: Confirmed → Invalid
status: Invalid → Confirmed
affects: firefox (Ubuntu) → firefox-3.5 (Ubuntu)
Changed in firefox-3.5 (Ubuntu):
assignee: Sameer Aslam (samalpha) → nobody
Micah Gersten (micahg) wrote :

Since this is already being worked on upstream, I'm marking this as Triaged.

Changed in firefox-3.5 (Ubuntu):
status: Confirmed → Triaged
hackel (hackel) wrote :

No apparent change in FF 3.6.3+nobinonly-0ubuntu4 in Lucid.

Changed in firefox:
importance: Unknown → High
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed

Can you please test this with a current Firefox version? Thank you!

Changed in firefox-3.5 (Ubuntu):
status: Triaged → Confirmed
status: Confirmed → Invalid
Changed in firefox (Ubuntu):
status: Confirmed → Incomplete

Setting to confirmed, let's see if there will be a Mozilla fix, not much activity in their bugzilla.

Changed in firefox (Ubuntu):
status: Incomplete → Confirmed
Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.