On Wed, Sep 16, 2009 at 1:53 PM, Maciej Stachowiak <m...@apple.com> wrote:
> I think a good way to deal with poorly written unload handlers is to > temporarily set the slow script timeout to a much lower value during > execution of unload. This would not require any JS-engine-specific changes > to work. There are two problems with this. First is the problem that, assuming today's "slow script" UI, this results in users being pestered about whether to kill the page that is trying to unload, which is unacceptable -- it effectively means that frequently, clicking a link or a close box results in a dialog box. The obvious answer is to modify the UX to just kill the script unilaterally without asking the user,at which point this becomes equivalent to my earlier proposal to simply terminate scripts after some amount of time, which is flawed (and can result in dataloss) due to wall clock time being a poor measure of script execution in some cases. (Consider a user closing a window full of tabs run in background processes that have been idle for some time and the OS has swapped out.) The better option, as Adam noted on the bug, is one in which the JS engine itself measures how much work has been performed. A count of instructions or function calls is a truer measure than the proposed count of time checks, but imposes costs on the JS engine that the V8 team have argued are unacceptably high, and has little real-world benefit (at the moment) over the current proposal, which approximates the same result in the types of unload handlers we see today. If authors modify how they write their scripts, we may need to revisit what an appropriate approximation would be, but the hope is to give them <a ping> at the very beginning, which benefits both them and their readers. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev