User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

1. Go to https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_checked
2. Click the Submit button
3. Click Back arrow

Actual results:

The whole page has been duplicated in a frame

Expected results:

The page should go back to the initial state.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Hi,

I have managed to reproduce this issue on latest FF release (67.0.4), Beta 68.0 and latest Nightly build 69.0a1 (2019-07-07) using Windows 7 and Windows 10.
I will move this over to a component so developers can take a look over it. I'm not sure if its the correct component since it might also be related to Bug 289323. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

(In reply to Alin Ilea from comment #1)

it might also be related to Bug 289323.

Unlikely. It looks like a quite recent regression.

Right, it's a regression and here is the regression range:

Last known good build: 20190227163104
First known bad build: 20190228214753

Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=198cd4a81bf2afa7cc79360f90da7bc91218b76d&tochange=fd53d5e80bca0316495a677b4155dabb1b771569

Bug 1489308 sounds likely. Could anyone verify that, pretty please :)

(In reply to Olli Pettay [:smaug] from comment #4)

Bug 1489308 sounds likely. Could anyone verify that, pretty please :)

Hi Olli,

I don't know exactly how I could help you more, but maybe is a good idea to ask Boris Zbarsky, the assignee of the bug that you mentioned above, to take a look over it. I will needinfo him and maybe he will help us.

Thanks.

Yeah, so if you load https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_checked and then examine frames[0].location.href in the console, you get "https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_checked" because that frame's content (the thing with the checkbox, etc) was created with document.open/write.

When we do the subframe navigation back, that's the URL we end up loading. Prior to bug 1489308 we would have loaded the written-out content due to the wyciwyg stuff, but of course all that has been removed. Per spec, I believe our current behavior is correct

Testing in other browsers, I see the following behaviors:

• Chrome shows "about:blank" in the subframe after clicking the back button.
• Safari navigates back at toplevel, not in the subframe when the back button is clicked.

Timothy, do you happen to know why Chrome is not following the spec here? It seems like it doesn't set the history entries up the way things are currently specced on open()?

glitched frames after refresh

Bugbug thinks this bug is a regression, but please revert this change in case of error.

If this is correct per spec, do we need to keep this bug open?

Well, it's not clear what the best thing is for web compat here and whether the spec needs changes...

OK, thanks. I can just leave it in the P2 bucket then for the Core::DOM folks, and I'll remove this from regression triage so release managers will stop poking it.

I tried to repro this and I see the same behavior in Chrome as Firefox, while Safari navigates back to "about:blank".
Olli, is this okay to close then if Chrome and Firefox both align presumably with the spec?

Redirect a needinfo that is pending on an inactive user to the triage owner.
:sefeng, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

I can repro the issue such that chrome navigates to "about:blank".

I don't think this is a P2 bug as this is more like a web-compact/spec issue. So I am decreasing the priority.

I don't think we want to close this. This is an odd edge case where browsers do different things.
I filed https://github.com/whatwg/html/issues/9330