Tested the issue in WebView. 

Steps Followed:
1. Enabled WebView
2. Installed WebView Demo debug
3. Clicked on Google + Reload
4. Observed do-reload=true

WebView versions tested:
64.0.3282.123

OS:
Android 7.0.0

Android Devices:
Samsung J7

@mike: Could you please find the above steps and let me know if I missed any steps from my end and also help us with a screencast for better understanding of the issue?

Thanks!!

Try the Blank + reload button. The child window (below the parent and above
the messages) should read "Window opened with window.open()." That is an
indication that http://localhost/opened was properly loaded. On my
Moto-Z-Play with WebView 64.0.3282.123, it stays blank, meaning that
about:blank was reloaded.

The message sequence is:

new DemoWebViewClient
handleRequest: http://localhost/already-opened?do-reload=true
onPageStarted: http://localhost/already-opened?do-reload=true
reloading
onPageFinished: http://localhost/already-opened?do-reload=true
onPageFinished: about:blank

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

BTW, the original problem was that in WebView 61, the Google button
resulted in a blank page/high CPU usage. The Google + reload method was the
temporary solution that worked.

Just thought I'd mention that I'm also trying to reproduce other weird
behavior in WebViewClient callbacks. I know that the WebViewClient
documentation says that onPageFinished() is called only for the main frame.
It seems that calling it multiple times for a single page load is not the
intent. In solidarity with document.onload(), this should mean that all of
the objects in the document are in the DOM, and all the images, scripts,
links and sub-frames have finished loading.

Here is a typical set of WebViewClient callbacks for a reasonably simple
page:

BrowserWebViewClient.onPageStarted ( 56 ): url:
https://an-internal-url/app/getDetails.do
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/app/getDetails.do
BrowserWebViewClient.onPageStarted ( 56 ): url: about:blank
BrowserWebViewClient.onLoadResource ( 40 ): url: about:blank
BrowserWebViewClient.onPageFinished ( 64 ): url: about:blank
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/app/res/style/common.css
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/app/res/style/menu.css
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/app/res/style/details.css
BrowserWebViewClient.onPageStarted ( 56 ): url:
https://an-internal-url/app/getDetails.do
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/app/getDetails.do
BrowserWebViewClient.onPageFinished ( 64 ): url:
https://an-internal-url/app/getDetails.do
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/app/res/style/print.css
BrowserWebViewClient.onPageFinished ( 64 ): url:
https://an-internal-url/app/getDetails.do
BrowserWebViewClient.onLoadResource ( 40 ): url:
https://an-internal-url/favicon.ico

You can see that onPageStarted and onPageFinished occur twice for the
getDetails.do resource and once for the about:blank one. I think that the
first one is aborted by the about:page sequence and then restarted. When I
look add a look at when document.onload() is fired, it seems to happen just
before the final onPageFinished. In the real world, these events happen in
a variety of orders, but the quantity and type of callbacks are the same. I
think it's reasonable to ensure that only one pair of calls is made, and
that except for when the actual url is about:blank the about:blank pair
should not occur.

It just seems desirable to give client code a reliable indication that the
actual page is finished loading. For my purposes, I can get a reliable
callback by attaching a javascript listener for the document load event and
generating my own, more accurate, onPageLoaded callback. I can also
leverage the symmetry of onPageStarted and onPageFinished callbacks, but
that might be less robust as WebView is updated.

Tested the issue in WebView and able to reproduce the issue. 

Steps Followed:
1. Enabled WebView
2. Installed WebView Demo debug
3. Clicked on Blank + Reload
4. Observed about blank page

Webview tested:
64.0.3282.123

OS:
Android 7.1.1

Android Devices:
Moto Z Play

Below are the manual bisect info

Good build: 61.0.3145.0
Bad build: 61.0.3149.0

Note: There are no builds available for WebView in between #61.0.3145.0 and #61.0.3149.0

Please navigate to below link for log's and video--
go/chrome-androidlogs/807770

Requesting MTV team to work on tool bisect for this issue.

Thanks!!

sandeepkumars@, can you please test on any Nexus or pixel devices too and let us know, so that we can work on per CL bisect?

In response to comment #8

Able to reproduce the issue using WebView version #64.0.3282.123 on Pixel with 8 OS. Observed about blank page.

Thanks!!

Sandeep, would you mind providing a per revision bisect, see #8.

Still need feedback here

Unfortunately triage team is having some issues in setting up per revision bisect tool. 

Padmaja, would you mind attempting when you get a chance.

I was unable to get a per-CL bisect as this issue seems to be happening even on system image :53.0.2785.124 on Nexus 6, though intermittently.

When tapped on Blank+reload button in the demo app, window opened with window.open() is displayed 3/5 times on M53. 

video & logcat @ go/chrome-androidlogs/807770_1

> 3. call WebView.reload() before WebViewClient.onPageLoaded()

Do you mean onPageStarted or onPageFinished?

Also that's the "child" webview, right?

> 4. sometimes about:blank is reloaded, not the desired page

Not really surprising. reload() reloads the last committed navigation, but there is no way for the app (or user of chrome) to actually observe when a navigation commits.

There is never a guarantee that reload does what you are expecting here, unless you wait for something like onPageFinished to happen first I guess. I'm not entirely sure if waiting for onPageStarted is good enough.

> > 3. call WebView.reload() before WebViewClient.onPageLoaded()
>
> Do you mean onPageStarted or onPageFinished?

The author means "onPageStarted." See the demo app [1].

I think the app should just wait for onPageFinished before calling a reload(). This doesn't seem like an unreasonable requirement, so I'm going to close this out.

[1] https://github.com/mikehat/demo-webview/blob/5c6f68c1c78881cf69f6e74a0747bc836449d4a2/src/main/java/com/luvcrew/demo/webview/MainActivity.java#L162