Clear child FrameNavigationEntries if a history navigation redirects.

content/renderer/history_controller.cc

Index: content/renderer/history_controller.cc
diff --git a/content/renderer/history_controller.cc b/content/renderer/history_controller.cc
index 14ced356b8896426cd4f027aac3ff5c594a45e46..dbdb11214fe277781b5e8f3857baf8952152aab7 100644
--- a/content/renderer/history_controller.cc
+++ b/content/renderer/history_controller.cc
@@ -177,6 +177,13 @@ void HistoryController::UpdateForInitialLoadInChildFrame(
     return;
   if (HistoryEntry::HistoryNode* existing_node =
           current_entry_->GetHistoryNodeForFrame(frame)) {
+    // Clear the children and any NavigationParams if this commit isn't for
+    // the same item.  Otherwise we might have stale data after a redirect.
+    if (existing_node->item().itemSequenceNumber() !=
+        item.itemSequenceNumber()) {
+      existing_node->RemoveChildren();
+      navigation_params_.reset();
+    }

[Charlie Reis, 2016/07/15 22:42:59]

This is actually the same fix I made to UpdateForCommit earlier this week in
https://codereview.chromium.org/2144823002/.  I didn't realize at the time that
the InitialLoadInChildFrame back/forward case had the same bug, so I'm fixing it
here as well.  (The new test in this CL pointed this out.)

Note: The previous CL was fixing a case that caused NC_AUTO_SUBFRAME kills.  I
don't think this instance of the bug can cause that, because the main frame
won't ever look cross-origin.  As a result, I don't think it's necessary to pull
this change out into a separate CL for merging.

     existing_node->set_item(item);
     return;
   }