Victor ADASCALITEI created CB-8107:
--------------------------------------
Summary: androidExec.processMessage possible miss behaviour
Key: CB-8107
URL: https://issues.apache.org/jira/browse/CB-8107
Project: Apache Cordova
Issue Type: Bug
Components: Android, CordovaJS
Affects Versions: 3.5.0
Environment: Android 4.4, Samsung Galaxy S4 Zoom, Chrome Version
39.0.2171
Reporter: Victor ADASCALITEI
[Cordova JS Build
3.5.0-dev-81f9a00|https://github.com/apache/cordova-android/commit/0add4af2081703961ab6c6567b7ad940932601a8]
introduced an _opt_useTimeout_ parameter to the _androidExec.processMessages_
function that uses JavaScript's co-operative multi-tasking mechanism to speed
up things through [window.setTimeout(androidExec.processMessages,
0);|https://github.com/apache/cordova-android/commit/0add4af2081703961ab6c6567b7ad940932601a8#diff-2c9fec471128ac99e3183c57bba8f2aaR1061]
.
I found this to cause problems in the following use-case: Suppose we have a
page using 2 JS scripts _A_ and _B_ (in this order). Both of them do some work
inside the _deviceready_ phonegap event and script _A_ produces something that
is consumed by script _B_ (like the loading of a config value, for instance).
Also, this is important to mention, both of the scripts use _phonegap_ plugin
calls inside their code regions.
Now, as _deviceready_ event is triggered, the first code that gets executed is
the one from script _A_. All is fine and dandy until it reaches the omnipotent
_cordova.exec_, call. At this moment, deep down in the call stack, cordova.js's
_window.setTimeont_ function *suspends* the execution of script _A_ and goes on
with processing script _B_'s _deviceready_ code *before* the plugin invoked by
_A_ has returned its value.
*This makes the behavior of the code difficult to control since the data flow
becomes chaotic.* Previous to this modification, script _A_'s code got fully
executed before script _B_'s code, as expected.
I used *chrome://inspect* for debugging and needless to say that, although the
invoked native android plugin code is a custom one, it doesn't use the
_cordova.getThreadPool()_ mechanism.
A quick fix to this issue is to bypass the _setTimeout_ region altogether by
running _androidExec.processMessages_ with _opt_useTimeout_ set to *false*.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
