I was able to reproduce this on my simulator every time. For some reason, switching from using blocks+dispatch_async to performSelectorOnMainThread fixes it. I've checked in this change, but we should definitely keep an eye out for any other cases of this.
On Sat, Oct 6, 2012 at 3:43 PM, Becky Gibson <gibson.be...@gmail.com> wrote: > It may not have been this explicit change - perhaps others that affect the > exec mechanism. Two places in the manual mobile-spec show the issue. In > contacts an alert is displayed with the success or failure of saving a > contact. In the Notifications if you test the Cordova Confirm, after you > dismiss it an alert is displayed to indicate which confirm button was > selected. I have other examples in my own manual tests to it isn't > mobile-spec related. > > -becky > > On Fri, Oct 5, 2012 at 2:28 PM, Andrew Grieve <agri...@chromium.org> > wrote: > > > I'm not sure why this would have changed. The PluginResult::success > method > > had a setTimeout in it, which I removed, but pretty much none of the core > > plugins used that method anyways. They all used writeJavascript:callback, > > which didn't use a setTimeout. > > > > The one spot in the code where I did see a comment about alerts causing > > deadlock worked around it dispatching using [self > > performSelectonOnMainThread:@selector(writeJavascript:) afterDelay]; > > > > This is what I've used to in the "new path" so that all plugins use it to > > avoid this case. > > > > What are the specific cases you're seeing? > > > > > > > > On Fri, Oct 5, 2012 at 2:06 PM, Becky Gibson <gibson.be...@gmail.com> > > wrote: > > > > > I am seeing instances where a JavaScript alert within a function > callback > > > will hang the app. We have seen this issue before and the solution is > to > > > wrap the alert in a setTimeout, for example, setTimeout(function() { > > > alert('error with ' + error.code); }); > > > > > > This problem now seems much more prevalent, especially with an iOS 5.1 > > > device. Could this be related to the exec speed improvements? If so > we > > > need to make sure to document the use of setTimeout() or folks are > going > > to > > > be unhappy when they go to run their apps. > > > > > > -becky > > > > > > On Fri, Oct 5, 2012 at 10:49 AM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > > > For those who didn't click the bug link to read the full benchmarks, > > I'll > > > > summarize: > > > > > > > > If exec() is called from the context of a plugin result callback: > perf > > > > improved *3x* [IFRAME_NAV] *6x* [XHR_NO_PAYLOAD] > > > > If exec() is called not from the context of a plugin result callback: > > > perf > > > > improved *66%* [IFRAME_NAV] *33%* [XHR_NO_PAYLOAD] > > > > > > > > Excellent work Andrew! > > > > > > > > > > > > > > > > On Thu, Oct 4, 2012 at 7:06 PM, Filip Maj <f...@adobe.com> wrote: > > > > > > > > > Sweet that sounds good > > > > > > > > > > On 10/4/12 2:20 PM, "Shazron" <shaz...@gmail.com> wrote: > > > > > > > > > > >+1 > > > > > > > > > > > >On Thu, Oct 4, 2012 at 2:18 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > >> nice! looks great andrew > > > > > >> > > > > > >> On Thu, Oct 4, 2012 at 10:48 PM, Andrew Grieve < > > agri...@google.com> > > > > > >>wrote: > > > > > >>> TLDR: Added a new method for plugins to use to send plugin > > results > > > to > > > > > >>>JS. > > > > > >>> > > > > > >>> I've done some work to try and optimize the exec() bridge on > iOS: > > > > > >>> https://issues.apache.org/jira/browse/CB-1579 > > > > > >>> > > > > > >>> The main goal of the change: whenever > > > > > >>>stringByEvaluatingJavascriptString is > > > > > >>> used to call a JS callback, poll for exec() messages using the > > > return > > > > > >>>value. > > > > > >>> > > > > > >>> The two ways plugins sent results in before my change: > > > > > >>> > > > > > >>> Before my change, plugins would send results using either: > > > > > >>> [self success:pluginResult callbackId:callbackId] > > > > > >>> or (more commonly) > > > > > >>> [self writeJavascript:[pluginResult > > > > toSuccessCallback:callbackId]] > > > > > >>> > > > > > >>> > > > > > >>> Both of these returned a string, which means I had to create a > > new > > > > > >>>method > > > > > >>> that could take advantage of the optimization. > > > > > >>> > > > > > >>> So, the new fancy: > > > > > >>> [self.commandDelegate sendPluginResult:pluginResult > > > > > >>>callbackId:callbackId]; > > > > > >>> > > > > > >>> And for custom JS callbacks: > > > > > >>> [self.commandDelegate evalJs:js]; // has a void return value. > > > > > >>> > > > > > >>> > > > > > >>> sendPluginResult: and evalJs:js have the extra bonus that they > > are > > > > > >>> thread-safe and they work around cases where an alert() in the > JS > > > > > >>>callback > > > > > >>> would result in dead-lock. > > > > > >>> > > > > > >>> I've left both of the old signatures so as to not break > > third-party > > > > > >>> plugins, but did go and update all of the core plugins. I'd > like > > to > > > > > >>> deprecate them. I'll go ahead and do that tomorrow probably. > > > > > >>> > > > > > >>> I plan on updating the plugin guide to use this new method. > > > > > > > > > > > > > > > > > > > >