[whatwg] about:blank synchronicity

[Maciej Stachowiak]

On Jan 13, 2010, at 5:22 AM, Henri Sivonen wrote:

> The HTML5 parser in Gecko loads all streams very asynchronously.  
> That is, to loading a stream never finishes from the same event  
> queue task that starts the load. This is fine for loading HTTP  
> streams, since the general expectation is that the process of  
> loading something from the network makes multiple trips through the  
> event loop.
>
> 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).
>
> 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.
> 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.
>
> As a result, in Gecko (with the old parser enabled), asking for  
> document.body of an iframe never returns null even if navigation to about:blank 
>  isn't complete. If the navigation hasn't completed yet, a body  
> element generated by #1 above is returned. If navigation has  
> completed, a body element generated by #2 above is returned. Since  
> #2 happens as a single task, it's never possible to see a browsing  
> context that is being navigated to about:blank in an intermediate  
> state of the parse. (The HTML5 parser breaks this by making the  
> state where the document object has been created by nothing has been  
> tokenized yet observable.)

Question: if you generate a document on the fly via early access, does  
it get replaced when the about:blank task actually completes?

It seems like if Gecko truly wanted to make about:blank synchronous,  
it should be possible simply by special-casing its load and performing  
a series of DOM calls right then and there, without ever involving the  
parser.

>
> Now, consider the following demo:
> http://hsivonen.iki.fi/test/bz-about-blank-data.html
>
> This makes it look like Opera and Safari were doing what the spec  
> says and navigating the iframe synchronously to about:blank. (The  
> use of the data: URL scheme makes the demo not work in IE.)
>
> However, if the data: URL is changed to an http: URL, Safari no  
> longer appears to navigate to about:blank synchronously:
> http://hsivonen.iki.fi/test/bz-about-blank.html

I think your test case demonstrates something that we would consider a  
bug. Though I am not sure what exactly is happening internally that  
causes it. We certainly make our best effort to load about:blank  
synchronously, though there may be unusual circumstances where that  
doesn't happen.

>
> Let's take a more careful look:
> http://hsivonen.iki.fi/test/bz-about-blank-check-body.html
>
> Opera indeed navigates to about:blank synchronously.
>
> IE doesn't support window.stop, so let's try testing without it:
> http://hsivonen.iki.fi/test/bz-about-blank-check-body-no-stop.html
>
> IE7 neither does IE 8 doesn't appear to actually navigate  
> synchronously.
>
> So it appears that only Opera is doing what the spec requires. Since  
> IE, Firefox or Safari aren't doing what the spec requires, what the  
> spec requires can't be exactly necessary for Web compat.
>
> What's the actual Web compat constraint when it comes to navigating  
> to about:blank (including loading about:blank as the initial page  
> into a newly-inserted iframe)?

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.

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.

Regards,
Maciej