[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Peter Kasting]

On Wed, Sep 16, 2009 at 1:53 PM, Maciej Stachowiak <mjs at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090916/e65ada8a/attachment.html>