Reload: propagate FrameLoadType to child frames

third_party/WebKit/Source/web/WebLocalFrameImpl.cpp

 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 1530 matching lines @@
     if (isBackForwardLoadType(frame()->loader().loadType()) && !frame()->document()->loadEventFinished())
         childItem = webframeChild->client()->historyItemForNewChildFrame();
 
     FrameLoadRequest newRequest = request;
     FrameLoadType loadType = FrameLoadTypeStandard;
     if (childItem) {
         newRequest = FrameLoadRequest(request.originDocument(),
             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
     // onload, so it is possible for the child frame to have already been
     // detached by script in the page.
     if (!webframeChild->parent())
         return nullptr;
     return webframeChild->frame();
 }
 
@@ skipping 586 matching lines @@
 {
     frame()->loader().forceSandboxFlags(static_cast<SandboxFlags>(flags));
 }
 
 void WebLocalFrameImpl::clearActiveFindMatch()
 {
     ensureTextFinder().clearActiveFindMatch();
 }
 
 } // namespace blink