Thanks for the update -- I don't think this is the same problem as the original one: Web player crash after the 1st script in a <batch>. That was an Inquisit bug affecting Windows (it did not affect OSX or iOS), and that one is definitely resolved in both 184.108.40.206 as well as the current 220.127.116.11.
The "This program is not responding..." message your participant reported is most likely caused by something else entirely. First a little background how <batch> elements work on the web. When you have
/ file = "A.iqx"
/ file = "B.iqx"
/ file = "C.iqx"
The web player will download "A.iqx" and all the files "A.iqx" may require (e.g. images). Once those files have been downloaded to the participant's device, "A.iqx" will be run. Once "A.iqx" has finished, the data gathered for script A will be uploaded and the web player will then proceed to download the next script "B.iqx" and its associated files...
Looking at your <batch> and the scripts / files involved
/file = "ConsentformScript.iqx"
/file = "worker_id.iqx"
/file = "conflictBoundPractice_v2overlap.iqx"
/file = "conflictBoundRetPractice.iqx"
/file = "conflictBoundMain.iqx"
the "not responding" issue occurs after "conflictBoundRetPractice" has finished, i.e. during the download process for "conflictBoundMain.iqx" and associated files. As far as I can see, Inquisit has to download _a lot_ of files for "conflictBoundMain", on the order of several hundred images (substantially more than for any other scripts). That takes some time (the sheer amount of files does cause a certain download performance hit, regardless of the sizes of the individual files involved, i.e., even if they are relatively small). During that time, it may indeed look as if the application has become unresponsive (although it is in fact still downloading files in the background); if -- in addition -- the participant's internet connection experiences a temporary issue (think: WiFi signal dropping for a short time) or is generally on the slow or unreliable side, the operating system would eventually determine that the application crashed and terminate it.
I unfortunately don't see any immediate workaround for this, unless reducing the number of files involved in / required by the "conflictBoundMain" script is an option.
I hope the above was not too technical or confusing.