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

Re: Newly-created browsing contexts and about:blank

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 3 Mar 2011 01:17:54 -0800 (PST)
To: Adam Barth <w3c@adambarth.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <462741518.496705.1299143874658.JavaMail.root@cm-mail03.mozilla.org>
Adam Barth wrote:
> I'm pretty sure WebKit fires the load event of <iframe
> src="about:blank"> synchronously.

Yes, it does.

> If compatibility allows, we'd
> vastly prefer to fire the load event asynchronously.

Gecko gets away with firing it asynchronously, so I'd expect WebKit to be able to be able to do the same.

For Firefox 4, the SVG load event was changed to fire asynchronously. Having events fire synchronously with the parse at points other than the script end tag is badness. I'd be very opposed to requiring events to fire synchronously with the parse (except at script end tag).

> Some thoughts:
> 
> 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.)

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

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

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Thursday, 3 March 2011 09:18:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:23 GMT