[whatwg] about:blank synchronicity
mjs at apple.com
Wed Jan 13 08:52:03 PST 2010
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
> Now, consider the following demo:
> 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:
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
> Let's take a more careful look:
> Opera indeed navigates to about:blank synchronously.
> IE doesn't support window.stop, so let's try testing without it:
> IE7 neither does IE 8 doesn't appear to actually navigate
> 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
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
More information about the whatwg