[whatwg] Avoiding synchronous iframe load
Ryosuke Niwa
rniwa at apple.com
Thu Oct 17 22:22:18 PDT 2013
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.
>> 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 at 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
More information about the whatwg
mailing list