[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 #28 from Peter Kasting <pkasting at google.com>  2009-09-16 14:33:16 PDT ---
(In reply to comment #27)
> (In reply to comment #26)
> > > 1) I think we should give web developers a bigger carrot to avoid an arms race
> > > here.  In particular, we should consider completing network requests started
> > > from unload handlers, removing the incentive to use a busy-loop.
> > 
> > There are a variety of serious problems with this.  Peter just touched on some
> > of them.  This been discussed to death already.
> 
> Are you referring to the passage where Peter says doing this provides authors
> no incentive to switch to <a ping>?  Darin also noted on IRC that this might
> slow down loading a new page from the same server.

Yes, I tried to mention both those issues in my comment, as well as the issues
that this can also slow down _other_ pages being loaded as well as all other
actions in the browser, and is also deleterious for other browser vendors and
does not result in the fastest possible tab closure.

Explicitly note that in IE, this is already the case (for image loads), and yet
authors busy loop in their unload handlers without regard to what browser is in
use.  Making the busy loop unnecessary is not nearly as good as providing a far
better solution at the same time that you make the busy loop not function.

In summary, this isn't a workable solution.  I have fought for it and thought
around it for quite some time and I can't support it.

> I think the main disagreement here is over how we think authors will respond to
> various incentives.  I don't think any of us know for sure.  As you've pointed
> out, they might even just ignore us given our market share.

There are three possible outcomes:
* Authors completely ignore this, in which case we have made users' lives
better.
* Authors move from the current code to <a ping>, in which case we have made
users of _all_ browsers' lives better, and made authors' lives better as well
(better guarantees on load completion).
* Authors ignore <a ping> and respond to this by finding some other way to busy
loop, in which case things are generally unchanged.

None of these things actively makes things terribly _worse_, and in the worst
case (case 3), we can choose how to respond, for example by counting more types
of instructions.

As I tried to note above, the current code doesn't work well for authors, so
their incentive to move to <a ping> once it's supported is greater than just
"we're going to make your current code not work".

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