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

Peter Kasting pkasting at google.com
Thu Sep 17 12:50:24 PDT 2009


On Thu, Sep 17, 2009 at 12:14 PM, Darin Fisher <darin at chromium.org> wrote:

> At any rate, I think I'm persuaded by your arguments.  Adam made a similar
> argument the other day too.  It seems reasonable to make Image behave this
> way when created in certain contexts.  We should probably include
> beforeunload and pagehide handlers since we have evidence that people do the
> same thing in beforeunload that they do in unload.  I include pagehide given
> the recent change to WebKit's page cache insertion policy.  We might even
> want to allow it in anchor tag click handlers for completeness.
>
> We should probably still consider an <a ping> implementation, but I agree
> that it doesn't have to be the only tool that we provide.
>

This conversation addresses the portion of the problem involving what
solutions we offer authors as an alternative to what they have today.

Any additional thoughts on the issue of how to make unload handlers fast in
the meantime?  It seems like we haven't reached agreement, particularly on
the issue of whether a timeout-based solution has worrisome possible
negative effects.

Perhaps there is some way to measure the efficacy and side effects of one or
both of these changes, so that we can experiment with them.  It's pretty
easy for us to add a histogram of unload handler wall-clock times, but I'm
not sure how we would detect the case that a timeout had prevented the JS
engine from executing enough of the unload handler (due to
swapping/GC/whatever).

At the very least, inserting John's change along with a histogram would
probably help answer questions like Maciej's earlier ones about how
prevalent this technique is and how much it harms users.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090917/8569d2b7/attachment.html>


More information about the webkit-dev mailing list