W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Avoiding synchronous iframe load

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 21 Jan 2014 19:26:48 +0000 (UTC)
To: Ryosuke Niwa <rniwa@apple.com>
Message-ID: <alpine.DEB.2.00.1401211916100.27706@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@MIT.EDU>, Elliott Sprehn <esprehn@chromium.org>
On Sat, 18 Jan 2014, Ryosuke Niwa wrote:
>
> 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’);

I encourage you to read the spec rather than rely on my interpretation of 
the spec, because if I made a mistake when writing the spec, I'm likely to 
make the same mistake when reading it, and thus it'll be missed, and doing 
what I describe in person will result in behaviour that is not 
interoperable with doing what I described in the spec.

But, with that caveat out of the way, here's what I think the spec says:

Creating the iframe does nothing interesting.
Setting the onload event listener does nothing interesting.
Appending the document triggers:

# 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

This leads us to "Otherwise, if the element has no src attribute 
specified, and the user agent is processing the iframe's attributes for 
the "first time"":

# Queue a task to run the iframe load event steps.
 -- http://www.whatwg.org/specs/web-apps/current-work/#process-the-iframe-attributes

So a task is queued. At this point, script continues, and we log "1".

After the script ends, we go back to the event loop and run the 
aforementioned task; the only step that matters for the test above is:

# 4. Fire a simple event named load at the iframe element.
 -- http://www.whatwg.org/specs/web-apps/current-work/#iframe-load-event-steps

This, via the event model in the DOM spec, ends up calling the lambda, and 
thus we log "2".

Thus, the spec says that it should log "1", then log "2".

Note that things are way more involved if you have document.write()s going 
on, or a src="" attribute (even if it is set to "about:blank"), or any 
number of other wacked things that the Web platform allows.


As a side note -- the javascript: handling rewrite that was prophesied in 
my earlier message on this thread has since occurred. I haven't checked 
how it impacts the earlier question.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 21 January 2014 19:27:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC