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.* Agreed? -Darin