- From: James Graham <jgraham@opera.com>
- Date: Mon, 30 Jul 2012 18:02:52 +0200
- 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 UTC