tom.williams Reporter
	Description • 22 years ago

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030116
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030116

When I access the "High FIdelity" page in a borwser tab, at the above URL,
Mozilla runs EXTREMELY slowly.  When I close that browser tab, Mozilla
performance returns to "normal".

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.highfidelityreview.com/news/news.asp?newsnumber=16781358
2. Mozilla performance should slow down when scrolling through the page or
navigating around the browser in general.
3.

Actual Results:  
Mozilla performance degraded severely.

Expected Results:  
Mozilla performance should NOT degrade to the point of almost being non-responsive.

	Ruslan Ismailov
	Comment 1 • 22 years ago

Well. I don't see performance drop, but I see that Mozilla eat 47-90% of comp's
resources. But when I load page in IE, IE start eating resourses at the same rate. 

	Markus Hübner
	Comment 2 • 22 years ago

Wow - really tough :/
confirming using trunk build 2003011412 on winxp pro sp1, 1.1ghz,512ram,
geforce2go,32mb ram

	tom.williams Reporter
	Comment 3 • 22 years ago

I'm running Windows NT 4.0 (SP6) ona Pentium II 400 MHz w/ 256 MB of RAM.

	Marius Strumyla
	Comment 4 • 22 years ago

the slowness is because of the background image
http://www.highfidelityreview.com/images/background.gif

using build 
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030119

possible dup of bug 64401?

	Marius Strumyla
	Comment 5 • 22 years ago

cc'ing myself

	Jean-Pierre Melkonian
	Comment 6 • 22 years ago

Same On MacOS 9.1

Memory used by mozilla (seen with "about this computer menu")

With the page opend in a tab : 82 Mb
After closing the tab: 35 Mb

	Café Internet @ CELAS
	Comment 7 • 21 years ago

Still happening with mozilla 1.5rc1 on W2K.

The page loads completly, and mozilla says it is "Done" but continues to use 80
or 90% cpu. Closing the tab restores things to normal.

	Mats Palmgren (inactive)
	Comment 8 • 21 years ago

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

	Olivier Cahagne
	Comment 9 • 21 years ago

*** This bug has been marked as a duplicate of 143046 ***

	Simon Montagu :smontagu
	Comment 10 • 21 years ago

Would this be better duped to bug 124150?

	Olivier Cahagne
	Comment 11 • 21 years ago

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

	Alex
	Comment 12 • 21 years ago

OK, I'm the one who posted the latest duplicate of this bug (#249966). As
reported above, the reason for all the problems is this large animated gif:

http://www.highfidelityreview.com/images/background.gif

Mozilla resizes this image to fit into the browser window. When the image is not
resized, CPU usage is modest (try using the "magnifying glass"). When the image
is resized, CPU usage is excessive. Memory usage is large either way, but
perhaps this is not mozilla's fault.

There are two simple workarounds for the problem. One is to allow animated
images to loop only once (Edit -> Preferences -> Privacy & Security -> Images).
This will affect all websites, of course, and will only solve the excess CPU
usage, not the excess memory. As a variant, there may be a way to stop images
being scaled to fit the browser window.

The second workaround is to add this image to your proxy's block list (I use
adzapper for squid, http://adzapper.sourceforge.net). This solves memory and CPU
usage without affecting any other websites (plus you can block all sorts of
annoying advertisements and conserve bandwidth etc.).

Hope this helps someone. It is not really clear from bugs #143046 or #124150 how
easy it is to fix the CPU usage in the mozilla trunk, or how soon such a fix is
likely to happen.