[whatwg] Avoiding synchronous iframe load

[Boris Zbarsky]

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.  :(

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'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