Re: Newly-created browsing contexts and about:blank

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