[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)
jam at google.com
Wed Sep 16 13:58:17 PDT 2009
On Wed, Sep 16, 2009 at 1:53 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Sep 16, 2009, at 11:23 AM, Geoffrey Garen wrote:
> Given some of our (Chromium-team) recent investigation into the contents
>>> of unload handlers, I'm not sure how much this move will help users, even if
>>> you don't revert it. Lots of unload handlers busy-wait while doing async
>>> XHR in order to try to guarantee delivery of tracking pings. Authors will
>>> probably elect to copy this code to the pagehide handler rather than moving
>>> it, and the experience for users is still going to be extremely sluggish
>>> navigation out of these pages.
>> While it's great that you've made improvements for unload handlers (or
>> maybe not-so-great, since you made them only in v8),
Note I had sent an email to a few WebKit folks to see if they're interested
in doing this in JSC as well, but since I didn't hear back, I kept it in V8
> 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.
I'm personally not a fan of the slow script dialog, as the average user
doesn't understand this enough to make a decision (i.e. they don't know if
they click this whether they'll lose data, they don't even understand what a
script is, etc).
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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev