PlzNavigate: identify same-page browser-initiated navigation.

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

Index: third_party/WebKit/Source/core/loader/FrameLoader.cpp
diff --git a/third_party/WebKit/Source/core/loader/FrameLoader.cpp b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
index 4ecd86acfe5d193b17657f2d080407ce30c033ae..80693b9449878eac51473cb430fce850ea03c4ba 100644
--- a/third_party/WebKit/Source/core/loader/FrameLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
@@ -1183,6 +1183,14 @@ void FrameLoader::load(const FrameLoadRequest& passedRequest,
     return;
   }
 
+  // PlzNavigate
+  // If the loader classifies this navigation as a different document navigation
+  // while the browser intended the navigation to be same-document, drop the
+  // navigation. A different navigation must have committed while the IPC was
+  // sent.
+  if (request.resourceRequest().isSameDocumentNavigation())
+    return;

[jochen (gone - plz use gerrit), 2016/12/21 10:30:58]

but if another navigation committed meanwhile, won't we need to do a "real" load
to get back to the original doc?

[arthursonzogni, 2016/12/21 13:24:29]

You mean relaunching the navigation, but this time from the renderer. That could
be a good solution.
Dropping the navigation is easier thought, and I think the difference is
imperceptible for the user. Let me explain:

If the users press ENTER immediately **after** the URL is modified in the
browser, the renderer-initiated page is displayed, the URL bar lose the focus
and the user press ENTER nowhere.
If the user press Enter an imperceptible moment **before** the URL is modified
in the browser, I think it's okay to display the renderer-initiated page too.
The user couldn't be sure at 100% that the URL bar's entry was modified before
or after they pressed ENTER.

If the browser-initiated navigation is dropped, the users will think that the
page navigated by itself just before they pressed enter, while it happened in
reality an imperceptible moment after they pressed enter.

No user could tell what solution we are using under the hood.
I think it doesn't worth trying to relaunch the navigation as other problems
that I am not aware of could occur.

For instance, if the navigation is relaunched, the page history will be (1 -> 2
-> 1#1). But the user will think it is (1 -> 1#1). They could be confuse when
they will do a back-navigation. It is better if the page history is (1 -> 2) and
the user think it is (1 -> 2) too.

Do you agree?

[clamy, 2016/12/22 17:30:25]

Actually, the time can be longer if for whatever reason the renderer was hung.

That said, I'm not sure if doing a fallback would be better from a user
perspective. Considering we just committed a new page, going back to the browser
and doing a network request in that case and committing the old page back might
be a bit weird.

If we want to preserve this behavior though, it's easy to send the request to
the browser from here. Just setCheckForBrowserSideNavigation on the
ResourceRequest to true and proceed. When we get to decidePolicyForNavigation in
startLoad the request will be sent to browser.

+
   startLoad(request, newLoadType, policy);
 }