Re: [whatwg] Avoiding synchronous iframe load

On Oct 25, 2013, at 11:42 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 15 Oct 2013, Ryosuke Niwa wrote:
>> Namely, in the following example, the first alert should be "true" as 
>> far as I read the specification.
>> 
>> <script> var a = false; </script>
>> <iframe src="javascript:a=true" onload="a = true"></iframe>
>> <script> alert(a); /* or even setTimeout(function(){alert(a);},0); */ setTimeout(function(){alert(a);},10) </script>
> 
> Well, javascript: is a bit of a weird case. In fact I'm planning on 
> revamping how that's specced shortly:
> 
>   https://www.w3.org/bugzilla_public/show_bug.cgi?id=13720
> 
> But right now, the above should alert false. Let me walk through why.
> 
> First, we start in the event loop, with one thread running. It picks up a 
> parser task, the parser inserts the <iframe> with its attributes set, and 
> that leads us to:
> 
> # When an iframe element is inserted into a document, the user agent must 
> # create a nested browsing context, and then process the iframe attributes 
> # for the first time
> -- http://www.whatwg.org/specs/web-apps/current-work/#the-iframe-element
> 
> So, first we create the nested browsing context:
> 
> # When a browsing context is first created, it must be created with a 
> # single Document in its session history, whose address is about:blank,
> # [...]
> -- http://www.whatwg.org/specs/web-apps/current-work/#browsing-context

Am I correct in assuming that load event never fires for this about:blank page since it’s “both ready for post-load tasks and completely loaded immediately"?

If so, that doesn’t match the existing behaviors of major browser engines.  For example, Firefox logs 1 then 2 in the following example whereas Chrome and Safari log 2 and then 1:
var iframe = document.createElement('iframe');
iframe.onload = function () { console.log('2'); }
document.body.appendChild(iframe);
console.log('1’);

- R. Niwa

Received on Sunday, 19 January 2014 04:35:07 UTC