Hi, Apologies for any potential mishaps as this is a first communication with the Cordova community. We may be reporting or shedding light on a known issue.
While hunting a bug on an S3 Neo android 4.3 device, resulting in file API not reporting success/failure during asynchronous calls, we had learned that OnlineEventsBridgeMode (NativeToJsMessageQueue.java) seem to be broken. We noticed that from a certain point in time, the Boolean *online* was always set to false during: toggleNetworkRunnable { ... webView.setNetworkAvailable(*online*) } Consequently there were no more online/offline events triggered at the JS and no more consequent polling of messages. To be more precise, events from JAVA to JS were delivered only when someone from the JS was calling androidExec (cordova.js) and never during online/offline events. As a result, we were always missing the last set of events as there were stuck down at the JAVA queue resulting in application freeze. (Once that started, the Boolean *online* was no longer being toggled via notifyOfFlush resulting in a permanent failure resolved only when reloading the software). As far as we understand, WebView only deliverers online/offline events to JS if the state of the Network changes i.e. if after a call to webView. setNetworkAvailable(*false*) one would call webView.setNetworkAvailable( *true*) and vice versa. This means that by design, Cordova seeks to maintain the Boolean *online* to maintain the inverse state of the WebView Network state. If/when the Boolean *online* looses track of the WebView Network state, the system online/offline events are discontinued until software reloading. Till now we were unable to track down the exact sequence leading the Boolean *online* to loose track of the WebView Network state in our system, but we do notice a sequence of two consecutive calls to notifyOfFlush, flipping the Boolean *online* twice - thereafter the Boolean *online* seem to have lost track of the WebView Network state and online/offline events no longer propagated to JS. If our understanding is indeed correct..... than, our main concern is that this design does not converge to a stable state and that inview of the asynchronous nature of the design and reliance on WebView specifics, a KISS methodology which would not put the code at risk of coming into a complete halt in view of a single mishap may be better. I.e. a design with a better self healing property following mishaps. We tried out a simple modification by replacing: webView.setNetworkAvailable(*online*); with: webView.setNetworkAvailable(*true*); // trigger an event webView.setNetworkAvailable(*false*); // reset the webView to its default state This had apparently solved the issues in our S3 Neo android 4.3 device though more testing are needed. If this approach is adopted, it requires cleaning up the code and removing now redundant code such as the notifyOfFlush mechanism which would no longer be needed, same for the JS event listener for offline events etc. This we hope would result in overall simplification of code in this area and better stability and endurance to mishaps. On the negative side, this alternative design results in doubling the amount of times in which webView. setNetworkAvailable() is toggled - forcing certain overhead. Yet, notice that there is no longer a need for cordova.js to listen to offline events, such that the added offline processing is now limited to the WebView internal overhead which is likely to be slim. Please advise, Reg, David Hadas