arielceb commented on issue #1007: URL: https://github.com/apache/cordova-android/issues/1007#issuecomment-652625392
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) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
