Malfunction OnlineEventsBridgeMode

[David Hadas <da...@gmail.com>]

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