1551529 - Navigating through multiple session history entries from iframe navigation results in iframes getting the wrong location

Status: NEW

(Core :: DOM: Navigation, defect, P5)

Description

[Johann Hofmann [:johannh]]

STR:

• Navigate to https://joo.crater.uberspace.de/frame-tester.html in a fresh tab
• Note that the iframe contains https://badssl.com
• Enter any valid URL (e.g. https://example.com) in the input field and press "Update URL"
• Now the iframe should contain https://example.com
• Enter any valid URL (e.g. https://example.com) in the URL bar, causing a top level navigation
• Long-click or right-click the back button to bring up the menulist
• Select the initial entry for "https://joo.crater.uberspace.de/frame-tester.html", just above "New Tab"

Expected Result:

The iframe on the page should contain https://badssl.com

Actual Result:

The iframe on the page contains https://example.com

This also reproduces for me when clicking the back button twice, the iframe doesn't go back to https://badssl.com but stays on https://example.com.

I'm not sure what exactly is responsible for this behavior, I suspect BFCache. I also assume this isn't intentional?

I found this while working on bug 1515073 and I initially thought my patch had caused this. This is definitely going to get more visible through bug 1515073 (though I would still say it's an edge case).

Comment 1

[Boris Zbarsky [:bzbarsky]]

This also reproduces for me when clicking the back button twice

This part I cannot reproduce. I can reproduce the STR that involve going back in history by 2 at once.

I suspect BFCache

Yep, that's it, good guess. If I add an unload event listener to the toplevel page, the effect disappears. This sort of makes sense: we restore from bfcache when going back by 2 in this case, but the bfcached thing is the state after navigation in the subframe (since it restores the DOM as it was when we left the page, not whatever is in the session history).

I'm not sure what the best solution here is, if any. We don't necessarily want to prevent bfcache restoration in this case, and we definitely do not want to prevent it if the multiple toplevel history entries are caused by anchor scrolls, not subframe navigations. On the other hand, if they're caused by pushState, we might be restoring a DOM that doesn't correspond to the URL in ways the app expects; not sure whether that's an issue in practice.

Comment 2

[Johann Hofmann [:johannh]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #1)

This also reproduces for me when clicking the back button twice

This part I cannot reproduce. I can reproduce the STR that involve going back in history by 2 at once.

Oh, I can't reproduce it anymore, either. Strange :|

I'm not sure what the best solution here is, if any. We don't necessarily want to prevent bfcache restoration in this case, and we definitely do not want to prevent it if the multiple toplevel history entries are caused by anchor scrolls, not subframe navigations. On the other hand, if they're caused by pushState, we might be restoring a DOM that doesn't correspond to the URL in ways the app expects; not sure whether that's an issue in practice.

Yeah, I don't think this will be a big issue in practice, even after bug 1515073. I just wanted to make sure we were aware of it.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

For now, P5, since it isn't clear whether we want to change behavior here.