Bug 27149
Summary: | JavaScript runaway script dialog. | ||
---|---|---|---|
Product: | WebKit | Reporter: | R Shan <mrithulashan> |
Component: | JavaScriptCore | Assignee: | 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 |
R Shan
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Could you please provide a specific test case? Also, have you tried Safari 4?
Gavin Barraclough
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.