Bug 52046

Summary: Navigation history inconsistent with FF/IE when using .open() on an iframe document
Product: WebKit Reporter: Darth <priyajeet.hora>
Component: FramesAssignee: Nobody <webkit-unassigned>
Status: UNCONFIRMED    
Severity: Normal CC: 83.samarth, achristensen, ahmad.saleem792, ap, arpitabahuguna, beidson, bfulgham, cdumez, creis, fishd, mihaip, priyajeet.hora, rniwa
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
iframe creation history entries test none

Darth
Reported 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> <html> <head> <script> function butt() { var frame = document.createElement('iframe'); frame.width = '500px'; frame.height = '500px'; document.body.appendChild(frame); frame.contentDocument.open(); frame.contentDocument.close(); frame.src = 'http://www.chromium.org/'; document.getElementById('history').innerHTML = window.history.length; } </script> </head> <body> <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> </body> </html>
Attachments
iframe creation history entries test (640 bytes, text/html)
2011-01-06 22:35 PST, Darth 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Darth
Comment 1 2011-01-06 22:35:51 PST
Created attachment 78212 [details] iframe creation history entries test
Arpita Bahuguna
Comment 2 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.
Ahmad Saleem
Comment 3 2022-05-30 09:13:18 PDT
From spec perspective, it was aligned with Chrome (Webkit) as per below: https://bugs.chromium.org/p/chromium/issues/detail?id=68833#c17 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!
Note You need to log in before you can comment on or make changes to this bug.