Processing iframe attributes is really confusing in terms of replacement enabled behavior

[bzbarsky]

The basic structure is:

The otherwise steps for iframe or frame elements are as follows:

...
3. Navigate the element's child browsing context to url.

And then there are some paragraphs of text, including:

Furthermore, if the active document of the element's child browsing context before such a navigation was not completely loaded at the time of the new navigation, then the navigation must be completed with replacement enabled.

and

Similarly, if the child browsing context's session history contained only one Document when the process the iframe attributes algorithm was invoked, and that was the about:blank Document created when the child browsing context was created, then any navigation required of the user agent in that algorithm must be completed with replacement enabled.

But chances are the spec reader has already clicked on the "Navigate" link and doesn't realize replacement is enabled.

[annevk]

I was just looking at this. Should we handle some this in the navigate algorithm directly? E.g., if the browsing context being navigated is a nested browsing context and its active document is initial about:blank, then set replacement enabled. It seems to apply to everything that creates nested browsing contexts.

[annevk]

@bzbarsky can initial about:blank ever be replaced with about:blank?

[bzbarsky]

Per spec as currently written, sure. <iframe src="about:blank"> or even just <iframe src>.

[annevk]

I couldn't really detect that happening in implementations though.

[bzbarsky]

If the question was what implementations do, I don't really know; I'd have to write careful tests and whatnot.

The replacement thing totally happens in Gecko. In fact it even happens for plain <iframe>, where it should not per spec.

[domenic]

This seems related to #2685 about no longer passing "replacement enabled" around implicitly.

[annevk]

This was fixed by 45b7b7b. Hurray!