Re: Newly-created browsing contexts and about:blank

On Thu, Mar 3, 2011 at 1:17 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> Adam Barth wrote:
>> 1) Normally, when the user agent performs a navigation, the window
>> object is replaced with a fresh new window object. This is not always
>> the case for about:blank documents. In some cases, global variables,
>> for example, are preserved after navigation. This behavior is also
>> related to whether the final navigation is same-origin with the
>> inherited security context for the about:blank document. You might be
>> interested in testing when this occur in various browsers.
>
> Interesting. I haven't tested this. However, as a side effect of testing window.open(), it turned out that when the pop-up blocker in Opera blocks a pop-up, the object returned by window.open() doesn't have script execution environment set up for it and doesn't have the methods an outer window usually has.
>
> (Even more curiously from a Web compat perspective, when the pop-up blocker in Firefox blocks a pop-up, window.open() returns null.)

I'm pretty sure this is required for web compat.  Chrome used to try
some tricks with off-screen popup that didn't return null, but that
confused sites that use the null return value to determine whether
their popups were blocked.

>> 2) The "sync plus single-task" approach for iframes is aesthetically
>> appealing. It would make loading an about:blank iframe more similar
>> to loading a normal URL in an iframe.
>
> I find it interesting that you find it aesthetically appealing. I think it's strange to have a behavior that's neither generating the about:blank DOM synchronously nor behaving equivalently to loading a zero-length stream over HTTP.

A conceptual model that seems to make sense here is the following:

1) When frames are created (either iframes or main frames), they're
created with a blank document.  That's why it's synchronous and the
load even doesn't fire: the document came into existence with the
frame.

2) Then, we perform an asynchronous navigation to the desired URL
(whether about:blank or otherwise).

3) For about:blank, the load completes atomically (which makes sense
because it's internal) and the load event fires as usual.

>> 3) Have you tested about:blank navigation via other APIs? For
>> example, what happens if you set the src attribute of an iframe to
>> about:blank if the iframe is currently displaying a normal URL?
>
> I haven't tested this.
>
>> 4) Have you tested about:blank in other contexts, such as img@src?
>> Does the error event fire synchronously?
>
> I haven't tested this, but I think making events fire synchronously in that case would be bad, since it would violate the expectations of when scripts can run relative to the parse.

Yeah, it's hard to be robust to running JavaScript synchronously at
these points, and we've had trouble there in the past.

Adam

Received on Thursday, 3 March 2011 21:22:38 UTC