Do not block document.written scripts in page reloads

third_party/WebKit/Source/core/loader/FrameFetchContext.cpp

Index: third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
diff --git a/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp b/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
index 27d945ba2eca6e0cfe8e6ccd10bfb288f1749d37..90c70752091b874fb4603c40663c661ad53aa06f 100644
--- a/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
+++ b/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
@@ -87,6 +87,17 @@ bool shouldDisallowFetchForMainFrameScript(const ResourceRequest& request, Fetch
     if (!document.settings())
         return false;
 
+    if (!document.frame())
+        return false;
+
+    // Do not block scripts if it is a page reload. This is to enable pages to
+    // recover if blocking of a script is leading to a page break and the user
+    // reloads the page.
+    const FrameLoadType loadType = document.frame()->loader().loadType();

[Bryan McQuade, 2016/04/21 20:54:42]

something to consider: do we only want to block on reloads if the
disallowFetchForDocWrittenScriptsInMainFrameOnSlowConnections setting is true?
if disallowFetchForDocWrittenScriptsInMainFrame is true that's more likely
because we're trying to test this feature out (either through finch trial to
canary or people have enabled it in about:flags) and in that case i wonder if
it'd be better to perform the intended behavior consistently, regardless of
reload or same page nav. i could imagine a googler testing this feature out for
example, loading a page, seeing that it was faster, then reloading over and over
and seeing that the feature seemed to be doing nothing / wasn't making the page
faster.

i could go either way here but want to make sure we take this into account as
part of this change. i am supportive of whatever you and josh decide.

[shivanisha, 2016/04/22 15:35:34]

If the only purpose of disallowFetchForDocWrittenScriptsInMainFrame is to allow
manual testing via about:flags , giving a consistent experience irrespective of
a reload sounds fine for ease of testing.

I am assuming the finch trial will still be based on
disallowFetchForDocWrittenScriptsInMainFrameOnSlowConnections? That's because we
would want the blocking to be disabled if a user reloads the page to allow for
breaking pages to recover. Is reaching a small population because of 2G a
concern for finch trial?

[jkarlin, 2016/04/22 15:44:47]

Yes, we're likely to want to expand to other network types, so we should avoid
blocking on reloads in those cases as well. Further, it's nice that the flag
mirrors the experiment so we can see how it will behave. I see your point though
Bryan, perhaps another flag that blocks even on reloads would be beneficial.

+    const bool isReload = (loadType == FrameLoadTypeReload || loadType == FrameLoadTypeReloadBypassingCache || loadType == FrameLoadTypeSame);
+    if (isReload)
+        return false;
+
     const bool isSlowConnection = networkStateNotifier().connectionType() == WebConnectionTypeCellular2G;
     const bool disallowFetch = document.settings()->disallowFetchForDocWrittenScriptsInMainFrame() || (document.settings()->disallowFetchForDocWrittenScriptsInMainFrameOnSlowConnections() && isSlowConnection);
     if (!disallowFetch)