Bug 52046 - Navigation history inconsistent with FF/IE when using .open() on an iframe document
Summary: Navigation history inconsistent with FF/IE when using .open() on an iframe do...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2011-01-06 22:34 PST by Darth
Modified: 2022-08-18 13:11 PDT (History)
13 users (show)

See Also:

iframe creation history entries test (640 bytes, text/html)
2011-01-06 22:35 PST, Darth
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Darth 2011-01-06 22:34:56 PST
Please use the file below.
Open it in IE/FF/Safari/Chrome, press the button a few times and observe the history entries of the browser.

FF/IE: history entry gets added per click
Webkit: no history entry added

Then comment out the 2 lines that deal with .open() and .close() and all the browsers behave similarly.

Unsure if this bug impacts much. Nothing is mentioned here
https://developer.mozilla.org/en/DOM/document.open about history
But I guess it opens with an empty origin, later src changes, hence a history entry.

<!DOCTYPE html>
		function butt() {
			var frame = document.createElement('iframe');
			frame.width = '500px';
			frame.height = '500px';
			frame.src = 'http://www.chromium.org/';
			document.getElementById('history').innerHTML = window.history.length;
	<button type='button' onclick='butt();'>Create iframe, then open() it and then close() it</button>
	History Length (should increment like FF/IE every button onclick): <div id='history'></div>
Comment 1 Darth 2011-01-06 22:35:51 PST
Created attachment 78212 [details]
iframe creation history entries test
Comment 2 Arpita Bahuguna 2012-03-07 23:59:22 PST
Not just for an iFrame but even otherwise back/forward navigation does not work as expected in case of document.open().

Currently Webkit does not seem to support the "replace" argument for the document.open() method.

As per the specification (http://dev.w3.org/html5/spec-LC/apis-in-html-documents.html#opening-the-input-stream) :
"If replace is false, then add a new entry, just before the last entry, and associate with the new entry the text that was parsed by the previous parser associated with the Document object, as well as the state of the document at the start of these steps. This allows the user to step backwards in the session history to see the page before it was blown away by the document.open() call. This new entry does not have a Document object, so a new one will be created if the session history is traversed to that entry."

The "entry" mentioned above refers to the History entry.

However, this seems to work well on FF and IE.

Additional test scenario:
Fetch: http://lava.access.co.jp/nmcstestsuite/Scheme/
Click on: "javascript_scheme"
On the following page click on "0" link.
Now navigate back to the starting page. Note that the second page is skipped.
Comment 3 Ahmad Saleem 2022-05-30 09:13:18 PDT
From spec perspective, it was aligned with Chrome (Webkit) as per below:


Further - based on JSFiddle - https://jsfiddle.net/u9tpz6ye/1/

Upon each reach Fiddle run and clicking on "button", it adds increment on Safari 15.5 but the behavior is inconsistent across browsers as below:

E.g. Chrome sometime start with 4 or 3 and same is with Firefox. I tried to use "Incognito / Private Mode" for this.

I think it is quite inconsistent and if we have WPT test cases to cover such behavior then good. Otherwise, it could be another webcompat issue. Thanks!