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

Re: Newly-created browsing contexts and about:blank

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 08 Mar 2011 09:39:18 -0500
Message-ID: <4D763F96.8060704@mit.edu>
To: Ojan Vafai <ojan@chromium.org>
CC: Henri Sivonen <hsivonen@iki.fi>, Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
On 3/8/11 3:58 AM, Ojan Vafai wrote:
> Closure's rich text editor (used in a bunch of Google products) relies
> on this behavior

Which exact "this behavior" of the many being discussed in this thread?

>(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);

This relies on there being a document synchronously available in the 
iframe.  The web relies on that, sure.  No one is planning to break it.

The open question is how that document got there and what events should 
be firing, and when, in that testcase.  Since you're ignoring all the 
events anyway, you don't really care about that part of the discussion, 
sounds like.

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

Which part of Gecko's behavior are we talking about here?  The fact that 
the about:blank loads async and will blow away a modified DOM if you 
modify it via DOM APIs instead of by doing a load yourself?  (Note that 
document.open() counts as a load here.)

-Boris
Received on Tuesday, 8 March 2011 14:40:24 UTC

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