[Webkit-unassigned] [Bug 29193] [chromium] Prevent JavaScript busy-loops in unload handlers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29193





--- Comment #24 from Peter Kasting <pkasting at google.com>  2009-09-16 12:15:52 PDT ---
Darin (Fisher), John and I had a long chat this morning in which we discussed
the ramifications of this and possible alternatives, as well as future plans. 
In short, I now support this change, although I admit it is a hack.  Gory
detail below if you care.

First, regarding the question of whether this change will solve the problem. 
According to John, comment 18 point 3a is inaccurate: basically all unload
handlers use this same technique to busy-loop.  Therefore, initially, this
change will make unload handlers run much faster.  As Adam notes, just doing
this alone could potentially lead to an arms race.  There are two reasons to
believe this is unlikely:

1) We propose to guarantee that by the time we ship this in a Stable channel
release, we will also have <a ping> available in the same release.  This gives
authors who care about our behavior an easier and
more-guaranteed-than-the-old-way mechanism.  Anyone who cares enough about
Chromium's behavior to rewrite their code will have significant motivation to
use this.

2) In the meantime, Chromium's market share (and, to be honest, WebKit's in
general) is too low for most authors to care.

Second, regarding future plans.  If we land this, we propose to also land some
logging/histograms of unload handler wall clock time and/or the number of times
this mechanism fires, so that we can measure its efficacy and the uptake of <a
ping>.  This can help us decide whether an arms race is actually occurring (and
if so what to do), or whether the hack has become sufficiently unnecessary that
we can just rip it out.

Third, regarding divergence.  As John mentioned, it's perfectly reasonable to
make this change for JSC too, and in fact I would prefer it, as it would be to
users' benefit and make the behavior of "WebKit" more consistent from an author
perspective.  However, note that the recent change to make pages with unload
handlers eligible for the bfcache means that unload handlers will rarely fire
where that is supported, meaning that authors may copy this code into the
pagehide handler, meaning that the hack might need to be expanded to also cover
pagehide for platforms with a bfcache.

Fourth, regarding alternate solutions.  I have been convinced by Darin that all
alternative solutions currently conceived are inferior in some way or other. 
Here are a scattering of examples:

* Hiding the page/tab while the handler is running suffers from numerous
problems, such as what to do if the handler fires an alert(), how to do this if
navigation is within the same domain or multiple windows can script this one,
and the jankiness caused by the renderer spinning the CPU and/or doing resource
loads in the background while the user is trying to load a new page.

* Trying to halt script using a different, less-workaroundable method such as
wall clock time, or instruction or function call count, suffer from
implementation problems, such as wall clock time being a poor bound if the
renderer ever has to swap from disk or gets suspended by the OS, or raw
instruction count access imposing significant constraints on the JS engine
design and API.  The V8 folks have indicated that this level of granularity
will cause them problems now and in the future, and I imagine similar things
might be true for JSC.

* In general, approaches which transparently allow authors to continue using a
mechanism like the current one provide authors no motivation to switch to <a
ping> (which would benefit users even if such approaches were implemented), and
effectively force all browser vendors to either copy this kind of hack or
continue to let their users suffer.  Providing both a carrot _and_ some kind of
stick should increase the likelihood of ending up in a better world, since
authors must hate the current code as it is fiddly and still doesn't actually
guarantee them that their tracking pings will complete.

* Not that this would be strong evidence by itself, but a number of different
Chromium team members familiar with different aspects of this (web authoring,
WebCore, V8, UI, etc.) have discussed this solution and its alternatives and
generally agreed that this is the best route.

Regarding the low-level details of how this patch is implemented, I am not
knowledgeable enough to comment, so I will leave that to Darin or John.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.