Tested the issue using #65.0.3325.109 on Pixel; 8.1.0 and could not reproduce the issue as per the steps mentioned below.

Steps Followed:
1. Launched Browser
2. Navigated to http://testsafebrowsing.appspot.com/
3. Clicked on a unsafe link
4. Redirected to safe warning page.

@ellisonchan13: Could you please update to latest version #65.0.3325.109 and check the issue?

Thanks!!

@sandeepkumars:
Thanks for your investigation.

I disabled chrome and updated webview to 65.0.3325.109 by Google Play on Pixel(8.1.0).
Then I tested my webview demo and could reproduce this issue again.
The reproducibility of issue is about 1/50.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Thanks for letting us know about this (and for integrating Safe Browsing in your app). It's hard to pinpoint exactly what could happen based on the description, so I have some follow-up questions for you:

 1. You said this repros 1/50. I assume that's 50 tries on the same device, with the same settings, right? Or is that 50 different devices?
 2. Does your app wait for startSafeBrowsing() to invoke the callback, or does loadUrl() sometimes come before the callback?

A couple other comments:

 * For future reference, you can keep chrome enabled, and update that instead. That's the default WebView provider, so updating chrome will update your WebView version. But what you did is fine too.
 * Our implementation communicates with Google servers to verify malicious URLs. If the servers take too long to respond, we have a 3 second timeout (at which point we treat the URL as "safe"). If you notice the page load is >= 3 seconds, that could explain what's happening. vakh@ may have more info on how frequently we hit this case.

Does the interstitial not show for the first URL after not having used Chrome or your app a while a.k.a. cold start?

If so, this is a known issue and it happens because on a cold start, it can sometimes take a bit longer for the GmsCore SDK to load the Safe Browsing database into memory after cold start. We have a plan to address this issue later this year.

vakh@ the WebView#startSafeBrowsing() API is supposed to get rid of the cold start (it uses SafetyNet#initSafeBrowsing). However, it only does that if the app waits for its callback before doing other loads.

Chrome can also "cold start" after a period of inactivity (after a timeout, it disconnects from GMS). However, WebView doesn't have the same disconnect-timeout.

I'm more curious about the case where the lookupUri() GMS call is so slow we kill it after the 3 second timeout, which I've only seldom noticed in the past.

@ntfschr
Thanks for your investigation.

>Question 1
This repros 1/50 on the same devcie.

>Question 2
Loadurl() method is invoked after startSafeBrowsing()'s callback is invoked.
Because I put the startSafeBrowsing() at Application's onCreate() and loadurl() at Activity's onCreate().
When this bug occured, I noticed that the startSafeBrowsing()'s callback had invoked and its value was true.

*I know it may update my webview version by updating chrome version directly.
And I had tested this too on Pixel with my webview demo. And the bug reproduced too.

*When this bug occured, I noticed that the page loaded slowly. And it probabaly took more than 3s.
It seems that it's the cause of this bug.

@vakh
Thanks for your investigation.

U say U found a known issue about cold start case.
Please tell me the issue's id when U have addressed the issue.

Thank you for providing more feedback. Adding the requester to the cc list.

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

> When this bug occured, I noticed that the page loaded slowly. And it probabaly took more than 3s. It seems that it's the cause of this bug.

If this took more than 3s, this is almost certainly the root cause. 3s is a policy decision. We could make our timeout longer than 3s, but it slows down the page load for users (and malicious pages are rare enough that this would probably do more harm than good). So I think this is working as intended.

> U say U found a known issue about cold start case.

To clarify, you are *not* affected by a "cold start" if you use WebView#startSafeBrowsing(). That API is eliminates the cold start.