Application fails with Webview / chrome 83

[arielceb]

Bug Report

App works properly until phone updates webview/chrome to version Chrome 83.0.4103.96 y WebView 83.0.4103.83 and greater.

What is expected to happen?

That the app ejecutes the callbacks when the app calls java code trough cordova

What does actually happen?

For example a button click event doesn't fire the first time the button is clicked instead fires the second time. In fact it happens with all events

Command or Code

Environment, Platform, Device

varios phones: xiaomi, huawei, samsung, motorola

Version information

Checklist

• [ ] I searched for existing GitHub issues
• [ ] I updated all Cordova tooling to most recent version
• [ ] I included all the necessary information above

[jcesarmobile]

I can’t reproduce , can you provide a sample app?

[arielceb]

android-debug.zip

[arielceb]

i uploaded a sample app. it has 3 buttons

$scope.Button1Click = function () { console.log("Button1Click call to java"); upsoft.movil.engine.GetUrl(function (res) { console.log("Button1Click res"); alert("Button1Click callback success"); }, function (err) { console.log("Button1Click err"); alert("Button1Click callback error"); }); }

$scope.Button2Click = function () {
    console.log("Button2Click call to java");
    upsoft.movil.engine.DeleteUrlTxt(function (res) {
        console.log("Button2Click res");
        alert("Button2Click callback success");
    }, function (err) {
        console.log("Button2Click err");
        alert("Button2Click callback error");
    });
}

[arielceb]

the first button get a string value from sharedpreferences

public String GetUrl() { SharedPreferences prefs = context.getSharedPreferences("managerNet", Context.MODE_PRIVATE); SharedPreferences.Editor editor = prefs.edit();
editor.commit(); return prefs.getString("URL", "");
}

and the second button deletes a file

public String DeleteUrlTxt()throws Exception {
    String res = "";

     File file = new File("/mnt/sdcard/ManagerMovil/url.txt");
     if(file.exists()){
        try {
            file.delete();
        } catch(Exception e) {
            throw e;
        } 
     }
     return "OK";
}

all using our plugin

GetUrl: function (successCallback, errorCallback) { var error = errorCallback; if (error == null) error = ErrorMovilEngane;

    cordova.exec(function (res) {
        if (VidarRespuesta(res))
        successCallback(($.parseJSON(res)).Res);
    }, error, "MovilEngine", "GetUrl", []);
},

DeleteUrlTxt: function (successCallback) { var error = ErrorMovilEngane; cordova.exec(function (res) {
if (VidarRespuesta(res)) successCallback(res); }, error, "MovilEngine", "DeleteUrlTxt", []); },

var VidarRespuesta = function (pOjb) {

var pOjb2 = $.parseJSON(pOjb);

var res = true;
if (pOjb2.TypeRes == 1) {
    //console.log("VidarRespuesta Res1: " + pOjb2.Res);
    usHelpers.Message.Progress.hide();
    usHelpers.Message.Alert(pOjb2.Res);        
    res = false;
}

[arielceb]

the problem with webview 83 its with the callbacks when you call a function, In the sample app. if you click the first button it must show alert("Button1Click callback success"); but nothing happens until you click again the first button or the second button

[jcesarmobile]

By a sample app I mean source code that can be run as an app, not the .apk. We don't ask for sample apps because we don't believe you, we ask because we need to be able to reproduce the issue, and be able to verify the issue is fixed, that can't be done with a precompiled apk because we can't change the native code there.

[arielceb]

PruebaWebView.zip

[arielceb]

PruebaWebView plugins.zip

[arielceb]

Sorry for the delay. i'll try to send you all the data to reproduce

[arielceb]

the first zip contains the app but it was greater than 10 MB, I have to split in two parts the second file contains the rest of plugins in the project

[arielceb]

i've sent previously the info to https://bugs.chromium.org ticket https://bugs.chromium.org/p/chromium/issues/detail?id=1090581

[arielceb]

So this is really fiddly to debug because of how complex all the cordova code here is, but it's not related to click events.

In the working case (81), from a fresh load:

• clicking the button fires a click, which eventually gets all the way down to movilengine.js's GetUrl function.

• This calls cordova.exec() to send a message to the Java code, with a result callback function which will pop up the alert box.

• This ultimately ends up calling a native method added by WebView.addJavascriptInterface to pass the parameters to Java, and this returns undefined as there's no queued messages from Java to JS waiting.

• At some later point, Cordova prods the online status of the WebView to trigger window.ononline, to indicate that there's a message waiting.

• Cordova's event listener for ononline polls for messages and gets the reply to the GetUrl message, calls the callback, and the alert box is shown.

In the broken case (tip of tree), from a fresh load:

• clicking the button works the same, calls the same cordova.exec

• The native method returns an actual message, for the "permissions" plugin, instead of undefined. this gets handled by the JS side of the permissions plugin.

• The online event never fires after that.

• The next time you click on a button, the native method returns the message that's still pending from the previous time around, so you get the dialog from the last click.

So, it seems like the Java Cordova code is not successfully notifying the JS code that there's a pending message it should poll for. There are online events being triggered, so the event for that is not broken, but it seems like something is getting confused about the queue state and not triggering the events when it should.

You may be able to work around this by changing the settings for how cordova communicates - it appears to have a number of different alternative ways to send/receive messages and to notify when there are pending messages, so maybe one of the alternatives isn't affected. Knowing what you have to change to get it to work might also help narrow the issue down?

I have no idea how this can actually relate to japhet's change, but it's definitely the CL that changed things here :(

I think someone who knows the internals of Cordova needs to debug this (which, unfortunately, is probably not anyone in Chromium), to work out what the actual change in Chromium behaviour is that is breaking the message queueing system. I don't know how to debug the Java side usefully - for it to be meaningful I would need to be able to debug the entire cordova library implementation at the source level and I don't know how to set that up in this test app (if it's even possible), and nobody on the WebView team is actually familiar with Cordova's implementation at all. The best option might be for one of the reporters here to file a bug against Cordova with their project code as a repro case and see if they can work out what the actual behaviour change is that affects cordova here - then we can probably work out whether this is a bug in Chromium or if Cordova was depending on some internal detail it shouldn't (e.g. depending on the exact ordering of things that aren't ordered, which is a common problem)

[breautek]

I tried your app against the latest version of cordova cli & cordova-android. There were a few problems.

1. the upsoft plugin does not exist, and was not included in your plugins zip. This doesn't prevent me from launching the webview, it just the buttons will not work (but I can see them responding to click events cause I see a stacktrace in the console).
2. The min SDK is not compatible with android 9, so I hacked it to force min sdk 22. (for some reason removing the android-MinSdkVersion preference wasn't enough), just so I can build and launch the app.

I'm using the latest android simulator, which had webview 83.0.4103.44, and I didn't observe the described fault. App launches, I click on a button, observed stack trace on first click, which means the click event is responding.

Personally I don't understand how cordova can influence native dom events. The cordova bridge is something completely unrelated to dom events, other than the cordova events like deviceready for example.

I realise that the original description used a later patch of the webview... and I'm currently waiting on my simulator to update (which seems to be taking forever for some reason), I'll post results as soon as it's done updating.

[breautek]

Upgrading to 83.0.4103.106 made no difference. Click events work.

Am I missing something?

[arielceb]

The upsoft plugin is in the file PruebaWebView plugins.zip in the folder PruebaWebView\plugins\ i recompile an tried it in a phone with android 8,1 and webview 83.0.4103.106.

[arielceb]

i used cordova version 9.0.0. Cordova Cli 6.0.0 to build the app with visual studio 2015. Maybe the was a bug in these version that was fixed in the next releases of cordova. The project was created several years ago and i have some troubles updating cordova with vs-tacc and several plugins

[breautek]

The upsoft plugin is in the file PruebaWebView plugins.zip in the folder PruebaWebView\plugins i recompile an tried it in a phone with android 8,1 and webview 83.0.4103.106.

This was not inside the plugins.zip file that you uploaded.

i used cordova version 9.0.0. Cordova Cli 6.0.0

The latest cordova versions are:

• cli: 9.0.0
• cordova-android: 9.0.0

I'm not expecting CLI 6.x to work properly with the latest versions of the platform and others. You may need to refactor your project to get it working on 9.x.

[arielceb]

to compile did you use Visual studio or other IDE or command line ?

[breautek]

I use the cordova cli

[manjunath143]

We are also hitting this issue on same devices ( Huawei, Samsung and Motorola ) with Android 9 and 10. We are using older Cordova Android source. Is there any PR or fix for this issue that we can back port it to older Cordova Android source ?

[jcesarmobile]

There have been a few issues with the chrome 83 update in a lot of devices from those vendors. I don’t think it’s possible to fix in cordova, the only solution is updating chrome to 84.

[manjunath143]

@jcesarmobile Thanks for quick response. Our users are reporting issue in Chrome 84 as well. Looks like it is not fixed yet.

[manjunath143]

The message queue system is broken on latest chrome releases. The message queue system is provided by Android SDK. We are using older Cordova Android which targets to older Android SDK. This issue is not seen in latest Cordova Android, we fixed this issue by changing target of the app to latest version in build.gradle in our older Cordova Android project.

[jcesarmobile]

thanks for the information, closing the issue then