See the linked page. The animation is javascript based image src replace. The freeze is probably related with the fact that the animation time isn't respected. There's no script stop at dom.max_chrome_script_run_time. Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b3pre) Gecko/2007121205 Minefield/3.0b3pre

This is not a regression; it happens also in old builds like Phoenix 0.3.

Similar situation(consumes CPU constantly, and memory size increases) was observed with Opera 9.23 when "speed value"(text field between "Play","slower" and "faster" buttons) is initially set to 1000, although CPU usage was a few %. And, when the "speed value" is set to 0 by "Faster" button, CPU usage becomes high like this bug, although CPU usage when "speed value"=0(seems to be interval) is smaller than CPU usage by Firefox/Seamonkey. When Seamonkey/Firefox, clicking of "Stop"(or "Pause") button stopped high CPU usage. And setting larger "speed value"(such as 2000) made Fx/Sm normal. And, setting to "speed value"=0 re-produced this bug's phenomenon. There seem to be two problems. (1) "speed value" is blank after page load when Fx/Sm. When Opera 9, this <input type=text> was pre-filled with "1000". (2) According to (1), "speed value" of ZERO is used by the Script, or incorrect "speed value" is used by the Script. And it is specified for setInterval or setTimeout. When null or invalid timeout value is specified for setInterval/Timeout, it is probably treated as ZERO by Fx/Sm. And, because timer fires very accurately than Opera, 100% CPU usage occurs when Fx/Sm, if timeout value=ZERO is specified. See Bug 332759, Bug 337540, Bug 337951, Bug 337956, for invalid timeout value. (bugs listed in dependency tree for Bug 332759. "Show Resolved" is required) For problem (2), I think that setInterval/Timeout(...,0) or setInterval/Timeout(...,Invalid) is better to be treated as larger one(such as "1000", 1 sec). I can say nothing about problem (1). I don't know whether script's fault or not.

Correction of previous comment. Sorry for spam. "speed value"=blank was done by script for "Stop" button. "speed value"=1000 was properly set initially by <input type="text" name="delay" value="1000"> in HTML. It looks that interval of 1000msec is too small for my environment. Note: When just after load and before start of CPU hog, "Stop" button works well. When my environment(Core2 Duo, 1.66GB), when delay=2000(interval value), CPU hog was not observed with Fx trunk 2007/12/31 build. But when delay=1800/1600, CPU hog started after a while, and Virtual Memory size increase also started. And refresh of image was almost stopped. When "Stop" button was clicked(in this case, able to click), "delay" field was changed to blank by Script after a while. And, CPU hog stopped, and Virtual Memory size returned to value before CPU hog(decreased from peak value). It looks following. When time interval becomes smaller than a threshold, contension among some tasks occurs. - setInterval/Timeout scheduling and Script execution - HTTP process by SRC change - Garbage collection It may intererfere tasks involved in contension. It may cause loop like situation. Example. (1) Too quick SRC changes of <IMG> interfere garbage collection. (2) Because interfered, garbage is not collected successfully. It may cause immediate retry of garbage collection. (3) Because of (1) and (2), next garbage collection have to check more and more. (4) Because of (1)/(2)/(3), it takes longer and longer.

Bug 410752, Bug 228233 look to be reports of similar problem.

Indeed.

This has nothing to do with bug 228233, as far as I can tell. There is no tight loop setting src over and over again without any timeouts in between. More importantly, this is reporting a performance problem, not a memory leak...

I profiled the freeze in this case. The basic toplevel breakdown is: 335057 nsTimerEvent::Run() 90616 nsImageLoadingContent::Event::Run() 26283 nsProxyObjectCallInfo::Run() It looks like there are a _lot_ of setTimeout calls and src sets involved. That shouldn't cause a freeze like this on its own. Martijn, Jesse, can you reproduce? If so, can you find someone try to reduce the page to something manageable (esp. the script parts)? Oh, and the total time spent in GC on this testcase is about 3%. And there are no calls to setInterval, just setTimeout. So comment 3 has no basis in reality, unfortunately.

It seems to me the cause of the problem is that there is: <img name="animation" src="" onload="setTimeout('animate()', delay)"> (see at the bottom of the source) So every time, the img src changes a new timer is fired, but the animate function also has setTimeout('animate()', delay); code in there. So we get increasing numbers of timers until the browser can't handle it anymore.

So this seems basically like bug 335256 to me.

(In reply to comment #7) > I profiled the freeze in this case. Thanks for profiling and explanation, and sorry for my very wrong guess. How can I do "profiling"? By Venkman?

I don't know if it's the same but I have a similar bug ***** Testing CONFIG: ***** - XP home sp2 - Java(TM) Platform SE plugin: all versions until 6 U5 - Firefox: all version till 2.0.0.14; 3b5 and Minefield 3.0pre 2008-04-27 - Brand new fresh profile - Default user agent ***** severity ***** - It completly freezes the browser after 3 or 5 minutes - firefox.exe process increases to 50% of CPU (dual core) - Process must be killed ***** Reproductivity ***** - Javascript must be enabled - Here is error console report, just go to the web site Error: banUrl[actualBan] is undefined Source File: http://www.laguitare.com/result_page.php?evt_type=SL&evt_id=0 Line: 41 or 44 (depends on ff version)

(In reply to comment #10) > So this seems basically like bug 335256 to me. > So, marking as a duplicate.