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.
> > > >
> > > >
> > >
> >
>
