Note: Above issue is also seen on all OS given below.
OS: Windows (7,8,8.1,10), Linux (14.04 LTS), Mac OS X(10.10.5, 10.11.4)

Good build: 54.0.2820.0 (409955)
Bad build: 54.0.2821.0 (410228)

Using hasbisect-per-revision script, multiple CLs are seen. From the CL found assigning the issue to the concern owner.

You are probably looking for a change made after 410148 (known good), but no later than 410155 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/42b13d59919ca019e92b4decd0e7db5a636b1c32..5a9a30409316fd19af685b1a88ae21b3e51e71c4

Suspecting Commit# 5a9a30409316fd19af685b1a88ae21b3e51e71c4
Suspecting Review URL# https://codereview.chromium.org/2194523002

@kenobi -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

This is a regression in M54 and per version bisect is provided. So please try to get this fixed ASAP.

This is marked as a stable blocker.  We're looking to ship that very soon, so please try to have this bug fixed no later than first week of October so that it can be merged to branch 2840 ASAP.

It could also be due to r410150, which changes how session history code works. Adding creis@.

Yes, it's almost certainly not kenobi@'s r410155, which is ChromeOS specific.  There's a good chance it's due to the new session history logic.  I'll try to look at in a debugger.

Apologies, I didn't see this until now.  It doesn't look like my issue, as creis@ observed, but I'm sorry I wasn't able to provide that input sooner.

I've started looking at this in a debugger.  The page has a lot of iframes (~47), many of which start at about:blank, and some of those which later go to a real URL.

The bug repros whether you click Next or go to a simpler site like http://csreis.github.io.  When you go back, some of the frames commit about:blank and are classified as NEW_SUBFRAME rather than AUTO_SUBFRAME (because params.did_create_new_entry is true).  As a result, we create a new NavigationEntry, which prunes the forward history.

It's not clear yet why params.did_create_new_entry is true for those frames.  For a history navigation, it should always be false, especially for about:blank.  No other commits are happening in those frames before the did_create_new_entry about:blank, so I'll need to look into why Blink is classifying it differently.

Unsurprisingly (for a page this complex), it doesn't repro identically each time, so hopefully we'll be able to boil it down to a simplified repro case.  So far, I'm seeing the incorrect NEW_SUBFRAME classification on frames with the following unique names:
<!--framePath //<!--frame12-->-->
<!--framePath //<!--frame13-->-->
<!--framePath //<!--frame14-->-->

Interestingly, frame12 and frame14 were not in the page the first time we visited it, but frame13 was.  All the other dozens of frames load correctly with AUTO_SUBFRAME.

I'll post another update when I know more.

Can we have the latest update of this issue?

I've narrowed the problem down to the "fallback" case for session history subframes, where the renderer process asks the browser process to find a history item for a newly created subframe (during back/forward), and the browser can't find one.  This can happen when the page changes between the previous visit and the current visit, adding frames that weren't there before (or that have different unique names).

When this happens, the browser process tells the new frame to navigate to the src URL of the new frame since it has no history item for it.  That's basically right, but apparently in some cases it gets treated as a new navigation rather than a history navigation, causing this bug.

I've been trying to write a minimal repro and test case for this, but none of the cases I've tried have worked so far.  We seem to usually classify the fallback case correctly as AUTO_SUBFRAME and not NEW_SUBFRAME.

However, I've already drafted a fix at https://codereview.chromium.org/2380943002/, which builds on my r420486 for  issue 638088 .  (Unfortunately, we'll need to merge both that and this new fix to M54, but I don't see a better way to do it.)  The basic idea is to tell the renderer process which frame unique names the browser process has history items for, so that it don't have to ask the browser process for other frames.  Thus, we generally won't hit the fallback case anymore.  (Ironically, I thought about including this in r420486 but decided to keep it simple at the time, to make it easier to merge.)

I'm trying to get the test to work this morning so that we can land the CL and let it bake.  We'll probably want to get the merge going for r420486 in the meantime.

Thanks for the active investigation.

After the CL lands we will test in canary. Please request a merge to M54 once its verified.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c8ca51e469c96ab4a3e1b0cd9772687077b38984

commit c8ca51e469c96ab4a3e1b0cd9772687077b38984
Author: creis <creis@chromium.org>
Date: Thu Sep 29 23:10:28 2016

Tell renderer which subframes have history items on back/forward.

This avoids making an IPC trip to the browser process for frames
that will not find a history item there.

BUG= 649345 , 639842
TEST=See bug for repro steps.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2380943002
Cr-Commit-Position: refs/heads/master@{#421972}

[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/browser/frame_host/navigation_entry_impl.cc
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/browser/frame_host/navigation_entry_impl.h
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/common/frame_messages.h
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/common/navigation_params.cc
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/common/navigation_params.h
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/renderer/render_frame_impl.h
[add] https://crrev.com/c8ca51e469c96ab4a3e1b0cd9772687077b38984/content/test/data/navigation_controller/dynamic_iframe.html

Confirmed that the fix seems to be working in 55.0.2876.0.

ligimole@: Would you like me to request a merge today, or wait until Monday?  

(I'll go ahead and request a merge for r420486 from  issue 638088 , since that has baked since 9/22 and is necessary for this.)

Could you please request a merge by tagging the bug with - Merge-Request-54.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c99ce14a59e2bc3fc9da83684748315ad5e2023

commit 1c99ce14a59e2bc3fc9da83684748315ad5e2023
Author: Charles Reis <creis@chromium.org>
Date: Sat Oct 01 02:52:31 2016

Tell renderer which subframes have history items on back/forward.

This avoids making an IPC trip to the browser process for frames
that will not find a history item there.

BUG= 649345 , 639842
TEST=See bug for repro steps.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2380943002
Cr-Commit-Position: refs/heads/master@{#421972}
(cherry picked from commit c8ca51e469c96ab4a3e1b0cd9772687077b38984)

Review URL: https://codereview.chromium.org/2385923002 .

Cr-Commit-Position: refs/branch-heads/2840@{#616}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_entry_impl.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_entry_impl.h
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/common/frame_messages.h
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/common/navigation_params.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/common/navigation_params.h
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/renderer/render_frame_impl.h
[add] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/test/data/navigation_controller/dynamic_iframe.html

Verified the issue on windows 10, Ubuntu 14.04 and Mac 10.11.6 using chrome beta version #54.0.2840.50 as per the comment #0
Observed that the fix is working as expected.

Attaching screencast for reference

Hence, adding the verified labels.

Deleted: 649345.ogv 13.8 MB

	649345.ogv 13.8 MB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c99ce14a59e2bc3fc9da83684748315ad5e2023

commit 1c99ce14a59e2bc3fc9da83684748315ad5e2023
Author: Charles Reis <creis@chromium.org>
Date: Sat Oct 01 02:52:31 2016

Tell renderer which subframes have history items on back/forward.

This avoids making an IPC trip to the browser process for frames
that will not find a history item there.

BUG= 649345 , 639842
TEST=See bug for repro steps.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2380943002
Cr-Commit-Position: refs/heads/master@{#421972}
(cherry picked from commit c8ca51e469c96ab4a3e1b0cd9772687077b38984)

Review URL: https://codereview.chromium.org/2385923002 .

Cr-Commit-Position: refs/branch-heads/2840@{#616}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_entry_impl.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_entry_impl.h
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/common/frame_messages.h
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/common/navigation_params.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/common/navigation_params.h
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/renderer/render_frame_impl.h
[add] https://crrev.com/1c99ce14a59e2bc3fc9da83684748315ad5e2023/content/test/data/navigation_controller/dynamic_iframe.html