This appears to be similar to this 2015 ticket that is still open: https://bugs.chromium.org/p/chromium/issues/detail?id=500260

In that ticket, someone suggested there that this issue applies to unnamed iFrames. We just tested adding a "name" attribute to an iFrame in addition to "id" that was already present, but its contents still got replaced with the contents of another iFrame when navigating back. See attached screenshot showing name attribute, and contents that are wrong.

Is there any known workaround until this can be fixed in Chrome? Thanks!

Deleted: Screen Shot 2017-10-05 at 10.05.34 AM.png 280 KB

	Screen Shot 2017-10-05 at 10.05.34 AM.png 280 KB View Download

In the comments of 500260 ojan@chromium.org posted over a year ago an awesomely simple repro, so copying it here so you don't need to follow the longer steps above.

1. Go to http://anforowicz.github.io/frame-creation-order/index.htm and observe red/green frames.
2. Close the tab.
3. Right click then "re-open closed tab".
4. Observe the contents of the red/green frames have switched.

Able to reproduce the issue on Mac os 10.12.6 , ubuntu 14.04 and windows 10 using chrome M61 #61.0.3163.100 and M63 #63.0.3235.0 as per steps mentioned in comment #3.

This issue is seen from M50 and is a non-regression issue.

Marking it as untraiged for further inputs on this.

Thanks!

This looks like a duplicate of  issue 500260 , but it is surprising that #c2 indicates that the issue doesn't go away after naming the frame.  FWIW, I cannot repro the issue when the frames are named - see http://anforowicz.github.io/frame-creation-order-with-named-frames/index.htm. 
 Maybe the name of the frame is set after the initial navigation in the frame (see  issue 607205  and RenderFrameImpl::DidChangeName method which skips updating the unique-name after the initial navigation).

ricky.blaha@, could you please clarify what you mean by "tested adding a "name" attribute to an iFrame" so that we can better understand your repro from #c2?

I had tried adding many variations of the simple test at http://anforowicz.github.io and yes as long as all frames had unique names it would work as expected, and when it was a mix between named and unnamed frames, only the unnamed frames were affected.

However when testing on aol.com those results did not carry over -- an async created named frame would still be replaced with the contents of an unnamed frames.

We have advised the site to name all frames, so they may make a change soon, but here are steps to repeat so you can at least see the issue I mentioned on Oct 5 happening:

1. Browse to https://www.aol.com/?atwCrPr=https://ibw.aol.com/IBW/creativePreview/1038012/index;970;250;0&atwUAC=adsWrapperName.js. This forces a 970x250 ad to appear at the top, and forces the fix of adding the "name" attribute to the async iFrame created for the results of the ad call.

2. See the 970x250 ad appear. Run this in the console to observe the iFrame containing the ad call has the "name" attribute: `document.querySelector('#atwAdFrame0')`. Expand the iframe in the console to see that the expected result is a div with an id of "adDiv" and some script tags that come from the ad call.

3. Click any content link then click back, and repeat a few times until you no longer see the 970x250 ad appear.

4. Once the 970x250 ad is missing, run this in the console to observe the iFrame containing still has the "name" attribute: `document.querySelector('#atwAdFrame0')`. Expand the iframe in the console to see that the contents have swapped with one of the other un-named iframes.

Run this in the console to see that there are currently 3 un-named iFrames on the page: `document.querySelectorAll('iframe:not([name])')`.

Hope that helps.

Thank you for the repro in #c6.  I tried looking closer and here are my notes:

One observation is that the atwAdFrame0 frame pointed out in step 2 in #c6:
1) has a name attribute (set to "atwAdFrame0")
2) doesn't have a contentWindow.name

    > var f = document.querySelector('#atwAdFrame0')
    ...
    > f.name
    "atwAdFrame0"
    > f.contentWindow.name
    ""
    > f.src
    ""
    > f.contentWindow.location.href
    "https://www.aol.com/?atwCrPr=https://ibw.aol.com/IBW/creativePreview/1038012/index;970;250;0&atwUAC=adsWrapperName.js"

In particular, it seems that we first create the frame with no name...

    FrameTree.cpp:66: SetName; pid = 71552; name = ""; this_frame_ = 0xa05ced3e388
    ...
    #2 0x7f58061a69a3 blink::FrameTree::SetName()
    #3 0x7f580594e570 blink::WebLocalFrameImpl::InitializeCoreFrame()
    #4 0x7f580594f763 blink::WebLocalFrameImpl::CreateChildFrame()
    #5 0x7f58057d3644 blink::LocalFrameClientImpl::CreateFrame()
    #6 0x7f58059f16ff blink::HTMLFrameOwnerElement::LoadOrRedirectSubframe()
    #7 0x7f58059eee24 blink::HTMLFrameElementBase::OpenURL()
    #8 0x7f58059ef904 blink::HTMLFrameElementBase::SetNameAndOpenURL()
    #9 0x7f58059efabe blink::HTMLFrameElementBase::DidNotifySubtreeInsertionsToDocument()
    #10 0x7f580546b1e0 blink::ContainerNode::DidInsertNodeVector()
    #11 0x7f580546bbb3 blink::ContainerNode::AppendChild()
    #12 0x7f5805575d6a blink::Node::appendChild()
    #13 0x7f58066b9376 blink::NodeV8Internal::appendChildMethodForMainWorld()
    #14 0x7f58066b9037 blink::V8Node::appendChildMethodCallbackForMainWorld()
    #15 0x7f58074bf2f2 v8::internal::FunctionCallbackArguments::Call()
    #16 0x7f58075ba953 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
    #17 0x7f58075b8b43 v8::internal::Builtin_Impl_HandleApiCall()
    #18 0x7f58075b850d v8::internal::Builtin_HandleApiCall()

... and only *later* set the frame's name *attribute*

    HTMLIFrameElement.cpp:126: ParseAttribute; pid = 71552; value = "atwAdFrame0"; ContentFrame() = 0xa05ced3e388
    ...
    #2 0x7f58059f6d7a blink::HTMLIFrameElement::ParseAttribute()
    #3 0x7f58054fda93 blink::Element::AttributeChanged()
    #4 0x7f58059dcbf7 blink::HTMLElement::AttributeChanged()
    #5 0x7f58055065c3 blink::Element::DidAddAttribute()
    #6 0x7f5805506505 blink::Element::AppendAttributeInternal()
    #7 0x7f58055103d6 blink::Element::SetAttributeInternal()
    #8 0x7f58054f8986 blink::Element::setAttribute()
    #9 0x7f5806939c31 blink::HTMLIFrameElementV8Internal::nameAttributeSetter()
    #10 0x7f5806939b06 blink::V8HTMLIFrameElement::nameAttributeSetterCallback()
    #11 0x7f58074bf2f2 v8::internal::FunctionCallbackArguments::Call()
    #12 0x7f58075ba953 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
    #13 0x7f58075b9204 v8::internal::Builtins::InvokeApiFunction()
    #14 0x7f5807b0700f v8::internal::Object::SetPropertyWithAccessor()
    #15 0x7f5807b1e53e v8::internal::Object::SetPropertyInternal()
    #16 0x7f5807b1e249 v8::internal::Object::SetProperty()
    #17 0x7f5807a13f94 v8::internal::StoreIC::Store()
    #18 0x7f5807a1ad10 v8::internal::__RT_impl_Runtime_StoreIC_Miss()

FWIW, HTML spec seems to say (https://html.spec.whatwg.org/#the-iframe-element):

    Whenever the name attribute is set, the nested browsing context's name must be changed
    to the new value. If the attribute is removed, the browsing context name must be set to
    the empty string.

OTOH, it seems to me that in https://crbug.com/632243 we are arguing that this propagation is not necessary and doesn't happen in other browsers.

+dcheng@ and foolip@ in case they want to add any comments wrt desirability of propagation of iframe.name changes into iframe.contentWindow.name.

Changing the iframe name once the subframe is created doesn't affect the browsing context name. This is a known bug and tracked in  issue 660485  =(

Thanks for the confirmation Daniel.  I guess as a workaround setting iframe.contentWindow.name should still work (at least for same-origin frames).

At any rate - the analysis above seems to show that this is indeed a duplicate of  issue 500260 .