[whatwg] about:blank synchronicity

Wed Jan 27 00:53:38 PST 2010

On Wed, 13 Jan 2010, Henri Sivonen wrote:
>
> This has turned out to be a test suite compatibility problem with 
> about:blank. Mozilla's Mochitest test suite has tests that depend 
> about:blank in iframe having a document.body immediately upon iframe 
> insertion to document without a trip through the event loop.
> 
> At first look, this seems like a clear case: the spec says that 
> about:blank is navigated to synchronously. However, this is not what 
> Gecko does (with the old parser).

The parser isn't even invoked in this case in the spec actually. Just 
creating an <iframe> and inserting in the document synchronously creates a 
Document object with the right elements, without parsing anything.

> Gecko (with the old parser) has these two characteristics:
>  1) If a browsing context that has no document object is asked to return 
> its document object, an about:blank-like DOM is generated into the 
> browsing context synchronously.

This is compatible with what the spec requires.

>  2) When a browsing context is navigated to about:blank, a task is 
> posted to the task queue. When that task is run, about:blank is parsed 
> to completion during the single task queue task.

I've changed the spec to make actual navigation to about:blank async.

On Wed, 13 Jan 2010, Maciej Stachowiak wrote:
>
> I am not sure what the exact constraints are, but I believe the 
> following are required:
> 
> - Accessing the document of a frame with missing, empty or about:blank 
> src has to always give you an HTML document with a body, even if there 
> hasn't been a chance for the event loop to run.
> - A newly created iframe with missing, empty or about:blank src has to have an
> accessible document right away, without even cycling the event loop.

I believe this is guaranteed in the spec, at least for newly created 
browsing contexts.

> There are at least three particular scenarios that are relevant here:
> 
> 1) Some sites document.write or otherwise poke at the DOM of their 
> about:blank frames or iframes in inline script, without waiting for the 
> load event or anything.
> 
> 2) Some sites load multiple frames, yet one expects to poke at the 
> other's DOM during its load. Since load order is not guaranteed, this 
> would be a race condition, if the not-yet-loaded frame had no DOM, but 
> synchronous about:blank lets such sites muddle on through. Before we had 
> sufficiently synchronous loading of the initial empty frame document, we 
> actually encountered sites like this that broke in Safari but not IE or 
> Firefox.
> 
> 3) Some sites make a new iframe element using DOM calls in an event 
> handler, and expect it to have an empty document that's immediately 
> ready for DOM manipulation, without any intervening returns to the event 
> loop.

Those should all work, since they all can access the initially created 
document (the one that doesn't involve a parser).

On Wed, 13 Jan 2010, Boris Zbarsky wrote:
> On 1/13/10 11:52 AM, Maciej Stachowiak wrote:
> > Question: if you generate a document on the fly via early access, does
> > it get replaced when the about:blank task actually completes?
> 
> Yes.  More precisely, the document is replaced, but the inner window is 
> not (the latter required for pages that set variables on the window 
> before the load is complete).

This is in fact required by the spec, too:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#create-a-document-object

> I believe Gecko treats a document.write the same way it treats a 
> location set in terms of network traffic: any loads that are happening 
> in that navigation context are canceled.  This is not specific to 
> pending about:blank loads.  For example, if you insert an iframe with 
> some http URI as @src into the DOM and then document.write into it 
> immediately, then the http load will be canceled.  Nothing special about 
> about:blank here.

This is currently step 8 of the document.open() algorithm.

> <!DOCTYPE html>
> <html>
>   <head>
>     <script>
>       function doTheTest() {
>         alert(window.frames[0].document.documentElement.textContent);
>       }
>     </script>
>   </head>
>   <body onload="doTheTest()">
>     <iframe src=""></iframe>
>     <script>
>       var doc = window.frames[0].document;
>       doc.documentElement.appendChild(doc.createTextNode("foopy"));
>     </script>
>   </body>
> </html>
> 
> This alerts empty string in Gecko (and doesn't show the string "foopy" 
> in the iframe).

The "" URL resolves to the same as "./", which in IE (though no other 
browsers) means loading up an actual page. Currently the spec agrees with 
IE on this, though there is an open issue about whether to change this 
that I haven't looked at yet.

If we have src="about:blank", though, the spec says that the <iframe> gets 
a Document object with its <body> created synchronously, and the 
navigation is never done; the DOM manipulation is thus persistent (and the 
test alerts "foopy")

On Thu, 14 Jan 2010, Henri Sivonen wrote:
> 
> Which leads to the question: Are there known Web compat constraints on 
> navigating a non-framed browsing context to about:blank via 
> window.open() or window.location.href in a previously open()ed window?

Currently the spec has no about:blank-specific magic for location.href or 
window.open() navigation of an existing browsing context as far as I 
recall. I'm not aware of needing any.

On Mon, 18 Jan 2010, Boris Zbarsky wrote:
> On 1/13/10 4:56 PM, Ian Hickson wrote:
> >
> > It seems like simply making the first one synchronous, but making the 
> > latter asynchronous, would satisfy your use case. Would other vendors 
> > be ok with this?
> 
> In case it wasn't clear from the relevant Gecko thread, I would 
> personally be fine with this.  That said, would "initial about:blank 
> load" only include <iframe/> (no src at all), or also <iframe src=""/> 
> or also <iframe src="about:blank"/>?  I suspect it doesn't matter that 
> much, actually, but would welcome confirmation.

See above for the "" case.

In the spec, src="about:blank" is treated specially now and avoids 
navigating. Omitting src="" altogether also doesn't navigate (though for 
subtly different reasons).

> > Would it have other problems? Are there cases other than navigation 
> > where about:blank being synchronous is detectable? (I couldn't find 
> > any.)
> 
> I'm not sure what you're asking here...

I mean, like, does it matter if about:blank is synchronous in <img 
src="">, or in CSS in a url(), or something like that?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'