[Android WebView] Synthesize a fake page loading event on page source modification

content/browser/web_contents/web_contents_android.cc

Index: content/browser/web_contents/web_contents_android.cc
diff --git a/content/browser/web_contents/web_contents_android.cc b/content/browser/web_contents/web_contents_android.cc
index 5e2b1284c7f186f55c9b27d8b0cffa4c0642622a..1c32a9b7f2ca117ac744e0d8b1cec784180c875a 100644
--- a/content/browser/web_contents/web_contents_android.cc
+++ b/content/browser/web_contents/web_contents_android.cc
@@ -480,4 +480,11 @@ void WebContentsAndroid::AddMessageToDevToolsConsole(JNIEnv* env,
       ConvertJavaStringToUTF8(env, message)));
 }
 
+jboolean WebContentsAndroid::HasPageScriptAccessedInitialDocument(

[Ted C, 2015/02/23 21:04:08]

Exposing this is a layering violation of sorts.  WebContents.java "should" only
expose methods from web_contents.h, but this is publicly exposing a
web_contents_impl.h method (actually a navigation_controller_delegate.h method).
 But we already do that so much in that file, so I guess you're not being
inconsistent :-/

Why does this name differ from WebContentsImpl's method?  We try to keep them in
sync.

[Charlie Reis, 2015/02/23 21:28:04]

Actually, why do we need to expose this?  In desktop Chrome,
WebContentsImpl::DidAccessInitialDocument calls
NotifyNavigationStateChanged(INVALIDATE_TYPE_URL), which chrome/ code uses to
reset the address bar to the new value of GetVisibleEntry.

HasAccessedInitialDocument is only used internally for implementing
GetVisibleEntry.

[mnaganov (inactive), 2015/02/23 22:17:55]

This is to avoid generating premature / superfluous OnPageStarted and
OnPageFinished events in WebView. I observed that NotifyNavigationStateChanged
for the URL is fired in the middle of page loading. If we will be
unconditionally synthesizing the events immediately, it will make clients to
believe that the page has done loading. And afterwards they will be receiving
another OnPageFinished via the regular means.

That means, we want to synthesize the events only when we are sure that this is
happening due to the document being accessed.

The difference between Chrome and WebView here is that WebView doesn't have an
API for controlling the URL bar. The only way we can make clients to update the
URL bar is to emulate page loading, which must not interfere with real page
loading process.

[mnaganov (inactive), 2015/02/24 11:28:42]

I agree, this isn't good, but as I have noted in my initial message,
other options like exposing the 'hasAccessedInitialDocument' on the public
interface, or duplicating WebViewImpl's logic for handling this property appear
even worse to me.
I though that a longer name is a bit more descriptive, but on the other hand,
having matching names simplifies searching, and it is easier to find the
original method, so changed the name to match the native one.

+    JNIEnv* env,
+    jobject jobj) {
+  return static_cast<content::WebContentsImpl*>(web_contents_)->
+      HasAccessedInitialDocument();
+}
+
 }  // namespace content