1368869 - History item added when an async document.write happens in an iframe

Status: RESOLVED INVALID

(Core :: DOM: Navigation, defect)

Description

[thirdpartybugs]

Attachment: ff-async-iframe-doc-write.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

Versions: 54.0b12 (32-bit)
Also reproducible on older versions, eg: v47, v31

*) open the attached html file
*) hit the browser back button



Actual results:

*) the content of the iframe was cleared



Expected results:

*) The browser should return to the previous page viewed before this file was opened

*) This is not reproducible on Chrome, EDGE, IE

*) The problem is when an iframe content document is written from an async 
(setTimeout) call

- see line 10 'doc.open()'of  attached file

- replace async line 18 with line 17, and the problem goes away

Comment 1

[Marco Bonardo [:mak]]

Please, don't more bugs into History:Global, it's mostly a dead component (we should probably file a bug to remove it).
If the bug is about History it should go to Firefox::Bookmarks & History, if it's about Session History (Back/forward) it should go to Core::Document Navigation

Btw, if I open the attachment in current tab, back works fine, if I open it in a new tab, back does what you said. I think this is correct.
If I open another page in another tab, and then the attachment, back works correctly as well.
So looks like something fixed this in 55?

Comment 2

[Andrew Overholt [:overholt]]

I think Samael knows about this type of situation.

Comment 3

[Samael Wang [:freesamael] (away for now)]

Adding an entry is indeed expected. See document open steps:
https://html.spec.whatwg.org/multipage/webappapis.html#document-open-steps
> 32. If replace is false, then add a new entry, ...
It seems Chrome & Safari don't align with spec at this part. Compare this demo in Firefox & Chrome / Safari and you can find the behavioral difference: https://codepen.io/anon/pen/KqPGGY?editors=1010

The reason that sometimes Firefox doesn't add that entry is sightly more complicated. Firefox treats new session history entries created during loading (i.e. any time before onload handler finishes) as redirections; it won't add these entries. What the attachment did is calling `createIframe()` at this end of main document's body. There's no guarantee that doc.open() happens after main document's onload finishes, even if there's a setTimeout. Try to open the attachment and refresh it multiple times, you might see different results. This should explain what :mak saw in comment 1.

If we move createIframe to main document's onload handler, then it should always add an entry: https://codepen.io/anon/pen/gRYqxG?editors=1010

And if you really don't want it to create an entry, replace `doc.open()` with `doc.open("text/html", "replace")`.

Comment 4

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Samael, if I interpret your comment 3 right, then there seems nothing we, firefox, would fix/change at the moment?

Comment 5

[Samael Wang [:freesamael] (away for now)]

Yup the behavior looks expected to me. Feel free to re-open if there're other evidence showing it's incorrect.

Comment 6

[Andrew Herron]

The ability to use doc.open("text/html", "replace") wasn't really documented (a note has now been added to the MDN page). I think that will solve our problem, thanks!