Re: [whatwg] Avoiding synchronous iframe load

On Oct 17, 2013, at 9:58 PM, Boris Zbarsky <bzbarsky@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.

>> I'm still somewhat puzzled by the fact processing the iframe attributes synchronously navigates to a new url (which itself could be async?) whereas following a hyperlink simply queues a task to navigate:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks
> 
> Gecko currently has that behavior: iframe @src changes start a navigation sync, while link clicks (and form submission) just post an event to start a navigation.  I wonder whether the spec simply specified that behavior....
> 
> The reason Gecko has the "post an event" behavior for link clicks is unclear to me.  The blame goes back to the initial revision of docshell/base/nsWebShell.cpp:
> 
>  1.1 <kipp@netscape.com> 1998-07-18 14:42
>  new
> 
> Not very helpful.  :(
> 
> All that said, I believe this stuff is all script-observable in the sense that it causes aborting of the document and whatnot.  Worth checking when/whether current UAs do that in the two cases.
> 
> -Boris

Received on Friday, 18 October 2013 05:23:21 UTC