[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)
mjs at apple.com
Wed Sep 16 21:59:04 PDT 2009
On Sep 16, 2009, at 4:49 PM, Darin Fisher wrote:
> On Wed, Sep 16, 2009 at 2:21 PM, Maciej Stachowiak <mjs at apple.com>
> 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
> 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
> 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.
Interesting - I don't recall every seeing false positives with
Safari's "slow script" detection. Maybe due to our particular timeout
design (see below).
> Counting work instead of time is much more robust. The getTime call
> counts is a measure of work, albeit approximate.
doesn't start ticking until JS execution begins. So it's unlikely that
a full timeout cycle will occur while the process is swapped out or
paused, since the clock won't start running until the process is
actually executing JS. And the actual timeout check is only done
occasionally (every N loop back edges or function calls, for some
value of N). So even if there's a context switch in the middle of JS
execution, it's unlikely that JS processing will be terminated
immediately upon return. So maybe a different solution is appropriate
> 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.
As long as the author installs their unload handlers before the ad
does, they won't have a problem.
To help us decide whether (and how) to tackle this for non-V8 ports of
WebKit, can the Chrome team share the data they have on the following:
(1) Frequency of pages doing a busy loop in an unload handler. I've
heard it's common but no specific data.
(2) A few examples of URLs to pages that do this, so we can study what
they are doing and why.
(3) Frequency of a date-based loop being used to implement the busy
(4) Average additional delay imposed by unload busy loops.
(5) Proportion of sites that use busy looping in unload solely for
link tracking and not for any other purpose.
The reason I'm interested in (1)-(4) is to determine if doing nothing
is really worse than doing something hackish, as suggested by Adam.
The reason I'm interested in (5) is to determine if <a ping> is an
adequate replacement. I think if we break existing techniques, we need
to give authors a replacement. unload fires when the user leaves the
page in any way whatsoever, including closing the window or typing in
the location field. So sites could use I/O in unload plus a busy loop
to track the amount of time the user spent on the page, or to save
state. If sites are doing that, then <a ping> won't be an adequate
replacement, so we'll have to do something like Adam's suggestion to
guarantee completion of I/O that is initiated in the unload handler.
The reason I think it's possible sites care about more than just link
tracking is that if that's all they care about, they could just use
redirect links, and get a better user experience today than busy
looping in unload. If sites are not using redirects for link tracking
today, why would they use <a ping> in the future?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev