On Oct 17, 2013, at 7:28 PM, Boris Zbarsky <[email protected]> wrote:
> On 10/17/13 6:14 PM, Elliott Sprehn wrote:
>
> > frame = document.createElement('iframe');
> > document.body.appendChild(frame);
> > frame.contentDocument; // synchronously available
>
> Yes, but at least in Gecko the frame.contentDocument you observe there is not
> the same as what you'd observer after at trip through the event loop. Again,
> we consider this to be a bug.
>
>> Also javascript: URLs are not async in Firefox:
>
> They most certainly are. I know because I made them so. ;)
Indeed!
>> Presumably all this behavior is required by spec.
>
> Whatever the spec requires can't match all UAs here, because UAs totally
> disagree on details of this behavior.
>
> This also means the spec might not be requiring anything particularly
> sane.... I suggest carefully reading it to find what it _does_ require right
> now, then fixing it as needed. ;)
As far as I read the spec, the navigation happens synchronously.
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element
When an iframe element is inserted into a document, the user agent must create
a nested browsing context, and then process the iframe attributes for the first
time.
...
When the user agent is to process the iframe attributes, it must run the first
appropriate steps from the following list:
...
If the value of the src attribute is the empty string, let url be the string
"about:blank".
Otherwise, resolve the value of the src attribute, relative to the iframe
element.
If that is not successful, then let url be the string "about:blank". Otherwise,
let url be the resulting absolute URL.
If there exists an ancestor browsing context whose active document's address,
ignoring fragment identifiers, is equal to url, then abort these steps.
Navigate the element's child browsing context to url.
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.
If gone async is false, return to whatever algorithm invoked the navigation
steps and continue running these steps asynchronously.
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
- R. Niwa
