- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 23 Oct 2013 17:57:00 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: whatwg@lists.whatwg.org
On Oct 17, 2013, at 10:22 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
> On Oct 17, 2013, at 9:58 PM, Boris Zbarsky <bzbarsky@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.
My preference is to match Firefox's behavior, and special-case about:blank to navigate synchronously but fire load event asynchronously.
i.e. what Boris said she wants Firefox to do.
That's probably the most consistent & Web-compatible behavior we can get.
- R. Niwa
Received on Thursday, 24 October 2013 00:57:28 UTC