Re: Newly-created browsing contexts and about:blank

On Mon, Mar 7, 2011 at 10:22 PM, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Mar 3, 2011, at 23:21, Adam Barth wrote:
> > 3) For about:blank, the load completes atomically (which makes sense
> > because it's internal) and the load event fires as usual.
>
> The problem with this model in Gecko is that the synchronous initial
> about:blank is semi-useless and confusing for authors. The author's script
> sees one about:blank, maybe adds stuff there using DOM manipulation and then
> the other about:blank loads and blows away whatever the author put in the
> first one.
>
> So the merit of Gecko's current model is that works with existing pages and
> test cases that already work in Gecko (obviously). The synchronous part is
> rather useless for authors beyond avoiding scripts crashing when scripts try
> to poke null document.body or something of that nature.
>

Closure's rich text editor (used in a bunch of Google products) relies on
this behavior (see
http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/editor/field.js#2461).
It uses iframes for the editing region. To avoid the delay waiting for the
load event, it essentially does the following:
container.appendChild(iframe);
iframe.contentDocument.write(initialHtmlContentsOfTheEditableRegion);

So, at least in this one instance it allowed a quite large performance
improvement. That said, Gecko's behavior is wacky. It would make a lot more
sense if the page was not blown away.

Ojan