Thanks for filing the issue.
1.Please provide the app package name .Is this the package name you are referring to
https://play.google.com/store/apps/details?id=io.plan.app.cordova
2. Please provide the NativeStorage Cordova plugin so testing team can try to repro the issue.
Please attach the Video for us to reproduce.Thanks

1) app package name: https://play.google.com/store/apps/details?id=com.portofantwerp.apicsmobile -> But it is currently the alfa (testing) version that fails, I have to verify that the released version is failing with the beta webview. As of friday normally it will ship to production.
2) https://github.com/TheCocoaProject/cordova-plugin-nativestorage/blob/master/src/android/NativeStorage.java 

As I am a beta tester of the webview I can confirm that the behaviour changed after the 71.0.3587.31 version.

I am seeing next stacktrace popping up frequently in LogCat (I do not know whether it is related to the changed behaviour)
11-07 16:14:39.209 17174-17197/? D/StrictMode: StrictMode policy violation: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
        at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1137)
        at libcore.io.BlockGuardOs.open(BlockGuardOs.java:182)
        at java.io.File.createNewFile(File.java:934)
        at java.io.File.createTempFile(File.java:1006)
        at com.google.android.play.b.s.b(SourceFile:58)
        at com.google.android.play.b.s.<init>(SourceFile:18)
        at com.google.android.play.b.g.<init>(SourceFile:79)
        at com.google.android.play.b.g.<init>(SourceFile:4)
        at com.google.android.finsky.e.w.<init>(SourceFile:95)
        at com.google.android.finsky.application.impl.c.a(SourceFile:1282)
        at com.google.android.finsky.application.impl.c.c(SourceFile:1291)
        at com.google.android.finsky.application.impl.c.cA(SourceFile:67)
        at com.google.android.finsky.application.impl.bo.a_(SourceFile:7)
        at b.b.a.f.a(SourceFile:11)
        at com.google.common.util.concurrent.s.a(SourceFile:5)
        at com.google.common.util.concurrent.r.run(SourceFile:17)
        at com.google.common.util.concurrent.bn.run(SourceFile:3)
        at com.google.android.apps.gsa.a.f.a.i.run(SourceFile:7)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at com.google.android.finsky.bn.w.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:818)

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

I stopped as beta tester and installed the 70 stable webview. The problem is gone. So, there is something wrong with the 71 beta webview. 
Kind regards, 
Pieter

Thanks pietervanpoyer@ for the details. We will check on M71 Beta with info #2 and see how it goes and update.

pietervanpoyer@ 
1. Unable to install the app from the playstore(after overriding the country code from the playstore) on the devices as it says the app is incompatible on the android devices.
2.Please add the issue as a video on the latest Beta build if reproducible.Thanks
So Can you please share the apk so we can sideload and install the app. Please do mention the playstore country for the apk to be installed on the test devices.

Apk is added as attachment.

Our country is Belgium. (BE?).
I enrolled again as Beta tester, and the issue persists.

I've installed the apk on an Android 5 device. It is strange that you have an error about an incompatible android device. 
I cannot give you credentials to log in to the app, but that wouldn't be necessary to see the problem.

Kind regards,
Pieter

Deleted: 10136 (2).apk 2.0 MB

10136 (2).apk 2.0 MB Download

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

I was able to install the app on Nexus 5, using "be" as the override on the Store's web interface. With WebView 70.0.3538.80, I see a login screen. With 71.0.3578.45, I see a blank screen. pietervanpoyer@, is this the bug? I don't see any StrictMode messages in the log in either case.

The blank screen is indeed the problem (no javascript coming through the native bridge).

Another Cordova based app that stopped working correctly:
https://play.google.com/store/apps/details?id=br.com.marcioggs.cordovashowcase&hl=nl
Install it, please, click the 'dialog' button.
Press Show dialog on the Dialog view.

A Dialog should be shown. Not shown on 71 beta, shown on 70 stable.
In cordova based applications, there is a javascript bridge to native Java code. This bridge seems to be broken. 

I see the Blank screen on latest 71 build on nexus 6P/OPM1.180608.001 and issue not reproduced in stable 70.0.3538.80 . Adding Need-Bisect and will work on bisect 

Ideally we need someone to share a test app with source code that has this issue.

I've provided a github repo:
https://github.com/PieterVanPoyer/showCaseCordova

There is an app-debug.apk in https://github.com/PieterVanPoyer/showCaseCordova/tree/master/platforms/android/app/build/outputs/apk/debug 

Run the app.
When you hit the Dialog button and on the Dialog page the 'Show Dialog' button, nothing is shown.
In logcat a log message appears: JsMessageQueue: Set native->JS mode to null

I will try to minimize the testcase, but that seems to be difficult.

Moving it to RBS.

I did add a branche at the git repo: https://github.com/PieterVanPoyer/showCaseCordova/tree/regression/chrome-web-view-71-beta
It shows a minimal setup (I think)
There is also an apk provided https://github.com/PieterVanPoyer/showCaseCordova/blob/regression/chrome-web-view-71-beta/platforms/android/app/build/outputs/apk/debug/app-debug.apk 

Testcase: hit Dialog button and on the Dialog page the 'Show Dialog' button, nothing is shown. In the 70 a native Dialog was shown.

Kind regards,
Pieter Van Poyer

Per-Version bisect information:
Good build:71.0.3578.18
Bad build:71.0.3578.20
Bisect range => https://chromium.googlesource.com/chromium/src/+log/71.0.3578.18..71.0.3578.20?pretty=fuller&n=10000
Unable to do a per CL Bisect.

nich

Guessing that this is caused by one or more of the origin-related issues covered in  issue 900528  and issue 896059.

Given the current per build bisect result 71.0.3578.18..71.0.3578.20, looks like it is a cherry-pick CL caused this issue, if this result is correct, this should not be the same to  issue 900528  or issue 896059.

I doubt our per CL bisect script works with this branch. + aluo@ to confirm with that. If that is the case, sbashyam@, could you please do per build bisect on version number ends with 0 builds only, so you could do per-CL bisect later.

If that bisect range is correct then this is Bo's change https://chromium.googlesource.com/chromium/src/+/26cedf8b88887de7991d68bfa478f54c4eee4863 almost certainly, having just looked through the list (I didn't notice this range before). Debugging this without a minimised test case will be hard but it's unlikely that any developers here are going to be able to provide one, because minimised here would mean "not using cordova" and just having the actual java/js code involved..

I don't have a test device with right now, so can't do anything helpful until next week.

The intended change in behavior is that WebViewClient.onPageStarted for some page loads come later (eg after onLoadResource), in case that helps you with anything in your app.

Also, onPageStarted will not be called until *after* it is too late to use addJavascriptInterface. It was never safe to call addJavascriptInterface from onPageStarted and assume that the loaded page will actually have access to the JS interface; it just used to be a race condition that you'd usually win, whereas now you will always lose. If any of the Cordova plugin code is trying to add a JS interface from onPageStarted that's likely the problem. (you shouldn't try to add/remove JS interfaces dynamically; just set them up once on the webview)

ctzsm is helping me doing debugging remotely. Here's the observation so far:

After my CL, there is an *extra* onPageStarted with no matching onPageFinished. The parameters to AwWebContentsObserver.didFinishNavigation are:
url:file:///android_asset/www/dialog.html
isInMainFrame: true
isErrorPage: false
hasCommitted: true
isSameDocument: true
isFragmentNavigation: false
pageTransition: 0
errorCode: 0
errorDescription: 
httpStatusCode: 200

Note that isSameDocument is true, but isFragmentNavigation is false. This turned out to be possible due to this code:
https://cs.chromium.org/chromium/src/content/browser/android/web_contents_observer_proxy.cc?rcl=5a0eb7284594a6e62033954deece1edb8ad0c21b&l=159

So apparently app is someshow navigating from file:///android_asset/www/index.html to file:///android_asset/www/dialog.html as a "same document navigation". I have no idea how that's even possible..

The answer is apparently history.replaceState navigations?
https://codereview.chromium.org/304763002

Then umm, are all webview browsers broken wrt history.replaceState and expecting the url to update?

If the app has enabled allowFileAccessFromFiles then all file:/// URLs are same-origin with each other, and as a result history.replaceState is allowed to change the URL in that way.

Triggering an onPageStarted for each of these URLs would be the sane/expected behaviour, since otherwise the URL bar can't be up to date. I'm not sure whether you'd expect to see onPageFinished for them or not.

Are you saying that before your change only one onPageStarted happened? Presumably just the first one, and the replaceState didn't trigger one? If so then I think that's an intended effect of your change and apps need to fix their code...

> Are you saying that before your change only one onPageStarted happened?

No. Before that CL, there is no onPageStarted for file:///android_asset/www/dialog.html, and there is no onPageFinished either. So I don't know for how long, but I think webview browsers would not update their url bar for push/replaceState.

> Triggering an onPageStarted for each of these URLs would be the sane/expected behaviour, since otherwise the URL bar can't be up to date.

Our solution to this for fragment navigations was to trigger a onPageFinished with no matching call to onPageStarted.

That's what I meant - the callbacks just didn't happen for the replaceState'd URL. Sorry if I worded it confusingly :)

Handling this like a fragment navigation seems like it makes sense. We have a lot of weird special cases here. I'm a bit concerned that changing the behaviour even more is going to result in yet more apps breaking in unexpected ways :(

So, just confirmed that on stable, a push/replaceState does not update the url bar in webview shell. So that's an existing separate bug. At least the fix is easy, change this to isSameDocument:
https://cs.chromium.org/chromium/src/android_webview/java/src/org/chromium/android_webview/AwWebContentsObserver.java?rcl=304f3ee41537a07c9f6d28b3ce6b31296b5cbe13&l=139

I'll file a separate bug.

Re #27, We confirmed that cordova apps are setting setAllowUniversalAccessFromFileURLs = true [1], saw this in our log too.

Assigning this Bo.

[1] https://github.com/apache/cordova-android/blob/46a036ef265951d5371936b37d7296fa47fb28ce/framework/src/org/apache/cordova/engine/SystemWebViewEngine.java#L164

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51748f6bd35ba31ea21d273961ad67120c405d38

commit 51748f6bd35ba31ea21d273961ad67120c405d38
Author: Bo Liu <boliu@chromium.org>
Date: Tue Nov 20 23:54:09 2018

aw: Skip onPageStarted for in-page navigation

This matches old behavior. Note that fragment navigation is strict
subset of in-page navigations. in-page navigations also include
history.replaceState and history.pushState

Bug:  902722 , 896022
Change-Id: I002fab4982620e7e13b84a7d96547e105c7338bb
Reviewed-on: https://chromium-review.googlesource.com/c/1345229
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Shimi Zhang <ctzsm@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609856}
[modify] https://crrev.com/51748f6bd35ba31ea21d273961ad67120c405d38/android_webview/java/src/org/chromium/android_webview/AwWebContentsObserver.java

M71 Stable cut is tmrw, please merge the changes to M71 branch assp.
Thanks!

satyavathir@, is that possible for us to verify this before merge, I think we also want to know if the new change breaks other cases (which should be low chance since this change is bringing an old behavior back.)

Verified on Pixel 2/PPR1.181005.003 having 72.0.3622.0 , issue not reproducible ,issue reproduced on latest 71 , requesting  to merge to M71 so we can verify the changes on M71.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Merge approved.

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/ede5172b9aed709b3950f89caa2aa1970a96a461

Commit: ede5172b9aed709b3950f89caa2aa1970a96a461
Author: boliu@chromium.org
Commiter: boliu@chromium.org
Date: 2018-11-27 16:49:14 +0000 UTC

[Merge M71] aw: Skip onPageStarted for in-page navigation

This matches old behavior. Note that fragment navigation is strict
subset of in-page navigations. in-page navigations also include
history.replaceState and history.pushState

(cherry picked from commit 51748f6bd35ba31ea21d273961ad67120c405d38)

Bug:  902722 , 896022
Change-Id: I002fab4982620e7e13b84a7d96547e105c7338bb
Reviewed-on: https://chromium-review.googlesource.com/c/1345229
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Shimi Zhang <ctzsm@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#609856}
Reviewed-on: https://chromium-review.googlesource.com/c/1351942
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#820}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ede5172b9aed709b3950f89caa2aa1970a96a461

commit ede5172b9aed709b3950f89caa2aa1970a96a461
Author: Bo Liu <boliu@chromium.org>
Date: Tue Nov 27 16:49:14 2018

[Merge M71] aw: Skip onPageStarted for in-page navigation

This matches old behavior. Note that fragment navigation is strict
subset of in-page navigations. in-page navigations also include
history.replaceState and history.pushState

(cherry picked from commit 51748f6bd35ba31ea21d273961ad67120c405d38)

Bug:  902722 , 896022
Change-Id: I002fab4982620e7e13b84a7d96547e105c7338bb
Reviewed-on: https://chromium-review.googlesource.com/c/1345229
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Shimi Zhang <ctzsm@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#609856}
Reviewed-on: https://chromium-review.googlesource.com/c/1351942
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#820}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/ede5172b9aed709b3950f89caa2aa1970a96a461/android_webview/java/src/org/chromium/android_webview/AwWebContentsObserver.java

Please verify on M71 once there's a build

Verified on Nexus 6P/OPM1.180608.001 having 71.0.3578.75 ,issue mentioned in comment #11 is no longer reproducible.Thanks for the fix.

Thanks for the effort. Works great now!
Chromium: Good luck with Edge!