Don't update subframes on parent frame commits.

content/browser/frame_host/navigation_controller_impl.cc

Index: content/browser/frame_host/navigation_controller_impl.cc
diff --git a/content/browser/frame_host/navigation_controller_impl.cc b/content/browser/frame_host/navigation_controller_impl.cc
index ac57709fb7e369bc449ea1f335c5dacb77fa1fb8..32975719bc7d66c22305f11be55068384a968a1e 100644
--- a/content/browser/frame_host/navigation_controller_impl.cc
+++ b/content/browser/frame_host/navigation_controller_impl.cc
@@ -1864,6 +1864,21 @@ void NavigationControllerImpl::FindFramesToNavigate(
         new_item->document_sequence_number() ==
             old_item->document_sequence_number()) {
       same_document_loads->push_back(std::make_pair(frame, new_item));
+
+      // TODO(avi, creis): This is a bug; we should not return here. Rather, we
+      // should continue on and navigate all child frames which have also
+      // changed. This bug is the cause of <https://crbug.com/542299>, which is
+      // a NC_IN_PAGE_NAVIGATION renderer kill.
+      //
+      // However, this bug is a bandaid over a deeper and worse problem. Doing a
+      // pushState immediately after loading a subframe is a race, one that no
+      // web page author expects. If we fix this bug, many large websites break.
+      // For example, see <https://crbug.com/598043> and the spec discussion at
+      // <https://github.com/whatwg/html/issues/1191>.
+      //
+      // For now, we accept this bug, and hope to resolve the race in a
+      // different way that will one day allow us to fix this.
+      return;
     } else {
       different_document_loads->push_back(std::make_pair(frame, new_item));
       // For a different document, the subframes will be destroyed, so there's