Reload: propagate FrameLoadType to child frames

third_party/WebKit/Source/web/WebLocalFrameImpl.cpp

Index: third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
diff --git a/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp b/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
index 9672566fe529b0560898a9a17ef532915fc524ee..8ef17ba87d5061d9c898af4665dc05a089c5628f 100644
--- a/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
+++ b/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
@@ -1548,6 +1548,8 @@ LocalFrame* WebLocalFrameImpl::createChildFrame(const FrameLoadRequest& request,
             FrameLoader::resourceRequestFromHistoryItem(childItem, WebCachePolicy::UseProtocolCachePolicy));
         loadType = FrameLoadTypeInitialHistoryLoad;
     }
+    if (isReloadLoadType(frame()->loader().loadType()) && !frame()->document()->loadEventFinished())
+        loadType = frame()->loader().loadType();

[Charlie Reis, 2016/07/22 20:44:00]

I don't think this will work for the new
SiteIsolationPolicy::UseSubframeNavigationEntries() path, which we're about to
turn on.

In that path, RenderFrameImpl::historyItemForNewChildFrame() always returns
null, and we punt the navigation to the browser process in
decidePolicyForNavigation.  The browser process looks to see if there's a
history item for the frame and then asks an appropriate process (not necessarily
this one) to load it.  If it found a history item,
RenderFrameImpl::NavigateInternal sets the load type based on
request_params.is_history_navigation_in_new_child.

As a side note, this seems like a possibly significant change to how we behaved
before, even in the default navigation path.  The try jobs on patch set 1
indicated some layout test failures as well, so I'm concerned about what impact
it has.  Can you investigate those, and add a test that covers the bug you're
fixing?

     webframeChild->frame()->loader().load(newRequest, loadType, childItem);
 
     // Note a synchronous navigation (about:blank) would have already processed