Bug 27149

Summary: JavaScript runaway script dialog.
Product: WebKit Reporter: R Shan <mrithulashan>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ap, barraclough
Priority: P2    
Version: 525.x (Safari 3.2)   
Hardware: Mac   
OS: OS X 10.5   
URL: http://trac.webkit.org/browser/trunk/WebCore/bindings/js/kjs_binding.cpp?rev=14904#L69

Description R Shan 2009-07-10 06:22:56 PDT
One of the programming barriers that we web developers are constantly bumping up against is the dreaded long-running script dialog (the runaway script dialog). These dialogs are displayed whenever the JavaScript code takes too long to execute. Safari does not determine slow script by total amount of statements the engine has executed. Looks like Safari uses script execution time (5 seconds to be exact) to determine if a a script is slow:
 
http://trac.webkit.org/browser/trunk/WebCore/bindings/js/kjs_binding.cpp?rev=14904#L69
[ Line # 72 ]

Firefox determines that a script is long-running by timing how long the script engine has been executing code continuously. The default time is set to 10 seconds and can be altered via about:config. [ Note that the amount of time modal dialogs, such as alerts, are displayed does not count against the script engine execution code]. When this execution time has been reached, Firefox displays the 'unresponsive script' dialog.

In Safari > Sure there is the Disable Runaway JavaScript Timer under > the Develop menu. But I have thousands of remote users for my application across the country. Instead of using "script execution time" can it be "total amount of statements the JavaScript engine has executed?" This should help application developers who use 'applets' to load them with out the 'slow script' error. Thanks.
Comment 1 Alexey Proskuryakov 2009-07-13 14:52:18 PDT
Could you please provide a specific test case? Also, have you tried Safari 4?
Comment 2 Gavin Barraclough 2012-03-13 13:40:07 PDT
I don't think that number of statements is going to be a viable metric here – I could make a single statement that is incredibly expensive!  Ultimately what we're trying to achieve it preventing JS execution from making a user's browsers unresponsive by running for too long.  Time is a better proxy for the amount of time used than statement count. :-)

I don't think statement-count is a better metric here.