[whatwg] Avoiding synchronous iframe load
Boris Zbarsky
bzbarsky at MIT.EDU
Thu Oct 17 21:58:07 PDT 2013
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
More information about the whatwg
mailing list