W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: Newly-created browsing contexts and about:blank

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 8 Mar 2011 19:58:36 +1100
Message-ID: <AANLkTikgNJuVi3YuX7SVZuj7E0WOVtoCThtggZpwhBsG@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
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
Received on Tuesday, 8 March 2011 08:59:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC