[whatwg] about:blank synchronicity

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

> 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.

Turns out this actually breaks at least some things that expect 
(asynchronous) onload events and the like for the about:blank load, at 
least when Henri tried doing exactly that.  I _think_ this was for cases 
where an explicit about:blank was listed as the src.  There is probably 
also various non-web code that expects various network events (start of 
network load, end of network load, etc) and the like in this 
circumstance...  We could try to hunt it all down and change it, but 
it's not exactly a trivial endeavor.  If it's necessary, it's necessary, 
of course.

> - 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.

Agreed.  This is an absolute requirement.

> - 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.

Yes.

> 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.

Yep.  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.

> 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.

Fully agreed on these use cases.

One question is whether in case 3 the sites expect the same DOM to be 
available later on.  It seems to be in Safari and Opera.  It's not in 
Gecko at the moment, as expected based on code inspection.   Testcase:

<!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).

-Boris

Received on Wednesday, 13 January 2010 09:08:59 UTC