W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] Load events fired during onload handlers

From: James Graham <jgraham@opera.com>
Date: Mon, 30 Jul 2012 18:02:52 +0200
Message-ID: <5016B02C.6010502@opera.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>, whatwg@whatwg.org
On 07/30/2012 05:44 PM, Boris Zbarsky wrote:
> On 7/30/12 11:10 AM, James Graham wrote:
>> I don't think I have a strong opinion about what should happen here, but
>> the Gecko behaviour could be easier to implement, and the WebKit
>> behaviour slightly safer (presumably the point of this anomaly is to
>> prevent infinite loops in load event handers).
>
> In Gecko's case, the only thing like that I know of is that onload fires
> synchronously in Gecko in some cases, I believe. So we had to put in
> some sort of recursion guard to prevent firing onload on a parent in the
> middle of a child firing onload or something like that.  See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=330089>.  Per spec, onload
> is always async, so this wouldn't be a concern.

Yeah, but as far as I can tell all browsers block (same document) load 
events that happen from inside onload [1], so I *guess* at some point in 
the past a site got into an infinite loop by trying to use document.open 
from inside onload.

> I'm not quite sure what causes the behavior you're seeing in Gecko at
> <http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1686>, but
> at first glance it's sort of accidental...  Which doesn't mean we
> shouldn't spec it, of course; it just means that figuring out what to
> spec is harder.  :(
>
> If desired, I can try to figure out exactly why there's only one load
> event on the first iframe there.  Let me know.

That would be really helpful.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17231
Received on Monday, 30 July 2012 16:03:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:09 GMT