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

Re: Newly-created browsing contexts and about:blank

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 2 Mar 2011 23:50:30 -0800
Message-ID: <AANLkTikobmkbBwnY59a4-h9MfReHEMFtCZKJddh=rCUi@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: HTML WG <public-html@w3.org>
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.

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.

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?

4) Have you tested about:blank in other contexts, such as img@src?
Does the error event fire synchronously?


On Wed, Mar 2, 2011 at 11:30 PM, Adam Barth <w3c@adambarth.com> wrote:
> I'm pretty sure WebKit fires the load event of <iframe
> src="about:blank"> synchronously.  If compatibility allows, we'd
> vastly prefer to fire the load event asynchronously.
> I'll try to find time to review your research in detail.  Sadly, I've
> spent a lot of time studying how about:blank works.
> Adam
> On Wed, Mar 2, 2011 at 6:39 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> I did some research on initial about:blank in newly-created browsing contexts:
>> http://hsivonen.iki.fi/about-blank/
>> Copying and pasting my conclusion:
>>  * When loading any URL in a window.open-created browsing context, initially create the DOM of about:blank there synchronously, since all browsers seem to do roughly that.
>>  * Since synchronous events are bad and Firefox gets away with not firing load synchronously for about:blank, never fire the load event synchronously.
>>  * Fire a load event asynchronously for the document that is the destination of the navigation.
>>  * If about:blank is the destination of navigation for window.open, use the initial synchronously-created DOM without overwriting it.
>>  * If about:blank is the destination of navigation for an iframe create the DOM synchronously ASAP as with window.open.
>> I am not sure what to think of the case where about:blank is not the initial destination of navigation for an iframe. Creating a synchronous placeholder about:blank DOM would make the browsing context code the same as in the window.open case and would provide an early document.body that scripts could accidentally poke without poking null. On the other hand, setting up such a DOM first and then letting the DOM be blown away by a later network task means that the presence of element nodes in the DOM would be racy relative to the network and to script getting appended to the DOM in the same parser task that appended the iframe. In that sense, the IE/Safari behavior would be nicer.
>> Opinions about the conclusion?
>> --
>> Henri Sivonen
>> hsivonen@iki.fi
>> http://hsivonen.iki.fi/
Received on Thursday, 3 March 2011 07:51:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:10 UTC