W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2010

[whatwg] about:blank synchronicity

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 13 Jan 2010 15:22:02 +0200
Message-ID: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
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.)

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

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)?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 13 January 2010 05:22:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC