Re: Newly-created browsing contexts and about:blank

On Wed, Mar 9, 2011 at 1:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 3/8/11 3:58 AM, Ojan Vafai wrote:
>
>> (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.


Correct. I was just responding to Henri's comment that "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.". The
synchronous part allows for the sort of use where you do the load yourself.


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

Yes, that part. I would describe that behavior as wacky. I get why it could
be simpler from a UA perspective (i.e. every url loads async), but I don't
think that would match most web developers intuition. If the iframe contents
are available and can be modified, they would expect the iframe to be loaded
and ready. Speaking purely from a web developer perspective, loading
about:blank documents synchronously, but firing the load event async would
be fine. The current gecko model just serves to trip up web developers until
they've learned this quirk.

Ojan