W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] requesting clarification for a "navigate with replacement enabled" case

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 28 Jul 2010 22:30:52 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1007282226300.7470@ps20323.dreamhostps.com>
On Wed, 7 Apr 2010, Darin Fisher wrote:
>
> Case #1:
> 
> var f = document.createElement("iframe");
> f.src = "http://foo.com/";
> document.body.appendChild(f);
> 
> 
> Case #2:
> 
> var f = document.createElement("iframe");
> document.body.appendChild(f);
> f.src = "http://foo.com/";
> 
> 
> My interpretation of section 4.8.2 is that in case #1 the iframe should 
> be navigated with replacment enabled, and in case #2 the iframe should 
> be navigated without replacement enabled.
> 
> I am basing that on the following passage:
> 
> > "Furthermore, if the process the iframe attributes algorithm was 
> > invoked for the first time for this element (i.e. as a result of the 
> > element being inserted into a document), then any navigation required 
> > of the user agent in that algorithm must be completed with replacement 
> > enabled."
> 
> That passage only specifies that in case #1 the navigation be completed 
> with replacement enabled.  It does not apply to the assignment of src in 
> case #2. I assume that means that the spec would have the frame 
> navigated without replacement enabled.
> 
> I raise this issue because I observe that Firefox and IE treat case #1 
> and #2 the same with respect to whether or not replacement is enabled.  
> They enable it for both navigations to http://foo.com/.  WebKit based 
> browsers (the latest stable Chrome and Safari) also happen to agree, but 
> that's because they always navigate with replacement enabled when the 
> src attribute is set, which is a bug.  WebKit nightlies behave 
> differently, and that is how I stumbled upon this issue.
> 
> I believe the spec for "src" assignment should match the spec for 
> location.assign:
> 
> > When the assign(url) method is invoked, the UA must resolve the 
> > argument, relative to the entry script's base URL, and if that is 
> > successful, must navigate the browsing context to the specified url. 
> > *If the browsing context's session history contains only one Document, 
> > and that was the about:blank Document created when the browsing 
> > context was created, then the navigation must be done with replacement 
> > enabled.*

That seems reasonable.

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 28 July 2010 15:30:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC