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

[Darin Fisher]

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

>
> On Sep 16, 2009, at 1:58 PM, John Abd-El-Malek wrote:
>
>
> Either way though, I don't think it'll work in this case.  I've seen pages
> have 8 beforeunload/unload handlers each sleeping for 200ms, just so that
> they don't have 1 handler that'll trip the slow script detection.  If we
> decrease the timeout for unload handlers, they would just increase the
> number of registered handlers proportionally.
>
>
> 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.
>


I too would like to avoid an arms race, but...

I disagree.  You'll get false positives at an unacceptable rate, especially
if you try to tamp down the interval to a small fraction of a second.  We
saw these problems in spades with Chrome's hang monitor (detecting
unresponsive subprocesses), and we had to push the interval to something
larger than we would have liked.

Counting work instead of time is much more robust.  The getTime call counts
is a measure of work, albeit approximate.

Also, it is very important to note that content authors are not entirely in
control here.  A content author may have some ads on their page, and it may
be the ad that is delivering the bad unload handler.  If we applied a limit
to all unload handlers, then we'd be punishing both the content author as
well as the ad provider.  That doesn't seem fair to the content author, who
might have a legit unload handler.

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