On Oct 17, 2013, at 9:58 PM, Boris Zbarsky <[email protected]> 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. >> 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 <[email protected]> 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
