[whatwg] Avoiding synchronous iframe load

Wed Oct 23 17:57:00 PDT 2013

On Oct 17, 2013, at 10:22 PM, Ryosuke Niwa <rniwa at apple.com> wrote:

> 
> On Oct 17, 2013, at 9:58 PM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote:
> 
>> On 10/18/13 12:39 AM, Ryosuke Niwa wrote:
>>> As far as I read the spec, the navigation happens synchronously.
>> 
>> It's worth defining "the navigation" in this context.  I assume you mean the invocation of http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate ?  If so, I agree that this is synchronous for iframes being added to the DOM as things are currently specced, as well as for @src changes on <iframe>.
>> 
>> This algorithm then synchronously performs certain steps.  Specifically, checking for scroll-to-anchor and doing the scroll.  At least as far as I can tell.  I don't know why it keeps checking the "gone async" value in steps 11, 12, 15, since nothing in the algorithm sets it to true until step 16 as far as I can tell.  Is "gone async" some sort of persistent state attached to the navigation, as opposed to the local variable it seems to be at step 7?
>> 
>>> Perhaps step 15 on http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate indicates the specification already mandates it to be asynchronous.
>> 
>> I can't tell what this specification is actually saying here, unfortunately.  Too much indirection.  :(
> 
> Yeah, I'm getting completely lost there.  Perhaps Ian could clarify what the current specification is trying to say there.
> 
>> The main hard design constraint I know of here is that navigating frames to about:blank via appending them to the DOM should ideally not change which document scripts see in the frame (though it does in Gecko right now; as I said we consider that a bug).  Whether this is implemented via some sort of synchronous navigation-like thing or via navigation preserving the document already in the frame seems like more of an implementation/specification detail than an observable thing...
> 
> I see.  Indeed, Firefox yields "false" but Safari, Chrome, and IE all yield "true" in the following example:
> <!DOCTYPE html>
> <body><script>
> var iframe = document.createElement('iframe');
> iframe.onload = function () { console.log('loaded'); }
> document.body.appendChild(iframe);
> console.log('appended');
> var doc1 = iframe.contentDocument;
> setTimeout(function () {
>   console.log(doc1 === iframe.contentDocument);
> }, 0);
> </script>
> 
> Here is the list of output each browser yields:
> Safari  / Chrome:
> 	loaded
> 	appended
> 	true
> Firefox:
> 	appended
> 	false
> 	loaded
> IE:
> 	loaded
> 	appended
> 	true
> 
> IE's behavior is interesting because it's synchronous. However,
> <iframe src="about:blank" onload="console.log('loaded')"></iframe>
> <script>console.log('appended');</script>
> yields
> 	appended
> 	loaded
> so IE might be behaving differently depending on whether the iframe is inserted by the script or not.

My preference is to match Firefox's behavior, and special-case about:blank to navigate synchronously but fire load event asynchronously.
i.e. what Boris said she wants Firefox to do.

That's probably the most consistent & Web-compatible behavior we can get.

- R. Niwa