- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Thu, 17 Oct 2013 21:39:05 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg@lists.whatwg.org
On Oct 17, 2013, at 7:28 PM, Boris Zbarsky <bzbarsky@mit.edu> 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
Received on Friday, 18 October 2013 04:39:30 UTC