Created attachment 54146 [details] Testcase When calling a slot from JavaScript, and that slot takes a long time to finish, QWebPage::shouldInterruptJavaScript() will not be called as soon as it normally would. This is because JavaScriptCore doesn't take into account that native function calls can take an arbitrary time to complete, so the timeout mechanism doesnt' kick in as soon as it could/should. Attached testcase reproduces this issue; normally (when the JS code is pure JS, or only makes "cheap" native calls), a messagebox asking whether evaluation should be aborted will pop up after 5-10 seconds, but that doesn't happen in this case.
Changing the value of ticksUntilFirstCheck from 1024 to e.g. 1 in JavaScriptCore/runtime/TimeoutChecker.cpp is a brute force fix for the issue; TimeoutChecker::didTimeout() will be called a lot sooner, and it will take the actual elapsed time into account when calculating the new value of m_ticksUntilNextCheck. This will of course cause a timeout check for even the smallest scripts. And it breaks down as soon as a script evaluates a lot of "pure" JS (causing a high m_ticksUntilNextCheck value), immediately followed by a lot of expensive native calls (causing the tick counter to be decremented very slowly again). Maybe JSC could use the CPU tick counter directly to decide when to call didTimeout(). (By http://www.fftw.org/cycle.h, for example)
> When calling a slot from JavaScript, and that slot takes a long time to finish, > QWebPage::shouldInterruptJavaScript() will not be called as soon as it normally > would. > This is because JavaScriptCore doesn't take into account that native function > calls can take an arbitrary time to complete, so the timeout mechanism doesnt' > kick in as soon as it could/should. Indeed, the timeout mechanism wasn't designed to put a time limit on native code -- only on JavaScript code. > it breaks down as soon as a script evaluates a lot of "pure" JS (causing a high > m_ticksUntilNextCheck value), immediately followed by a lot of expensive native > calls (causing the tick counter to be decremented very slowly again). Right. I don't think an initial tick count of 1 would solve your problem. > Maybe JSC could use the CPU tick counter directly to decide when to call > didTimeout(). (By http://www.fftw.org/cycle.h, for example) I'm not familiar with this kind of counter. I guess the way to decide whether to use it would be to performance-test it. I think the best possible option would be to poll a memory location for a "timed out" flag, and to use an OS timer to set the "timed out" flag. Once again, performance might be an issue, since we'd be changing a test-and-decrement of a register into a test of a memory location.
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.