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

[Peter Kasting]

On Wed, Sep 16, 2009 at 2:21 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> I think that setting an upper bound on the amount of time that can be spent
> in all unload handlers is a better solution than hacking the behavior of the
> Date API. Because (a) It's less likely to have unexpected side effects; and
> (b) there's no way for content authors to work around it, so we are less
> likely to end up in an "arms race" situation. There were worries expressed
> that swapping or context switching might trigger false positives, but I
> expect this is unlikely in practice, based on our experience with the slow
> script dialog.
>

These were also my arguments.  And I think all of us agree that in principle
setting a generic execution limit would be better.  In practice, we have
strong reason to believe that false positives will be common with wall clock
implementations, at least for Chromium (because of our multiprocess design,
renderer swapping is actually a huge issue for us currently, which we're
trying to address), and that it's still easy for authors to work around this
even at low values like 100 ms (instead of 8 200 ms handlers, just kick off
32 50 ms handlers.  Repeat ad infinitum).

The goal of this change is to approximate an execution limit in a way that
does not suffer from false positives and is also reasonable for a JS engine
to implement, and to do it temporarily while providing <a ping> until the
point when measurements show that authors have in general switched to use
that.

As I tried to say on the bug, even the worst possible outcome, an "arms
race", doesn't actually result in net harm, and if it happens, we can decide
whether to try and shift the approach to be more like this, or to give up
and rip out the hack entirely.

>From reading the comments in the bug, it does not look like we have
> consensus on the right approach, even among Chrome developers.
>

This is correct, but somewhat misleading.  Adam is to my knowledge the one
Chromium developer, who only recently encountered this idea, who currently
disagrees, compared to a large number of us who agree.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090916/32a9cfd0/attachment.html>