incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Schulkind <mschulk...@gmail.com>
Subject Re: new iOS command queue may have broken innerHTML fix
Date Tue, 25 Oct 2011 22:29:34 GMT
I have had tons of problems with UIWebView in general, so much so that I've
just about finished abandoning it. I've been working on a set of native UI
components for Callback (that sounds weird...), so I luckily don't need the
HTML display of UIWebView, so I'm currently 90% of the way to integrating
SpiderMonkey with phonegap, which totally gets rid of any exec() type
problems because you get to use a real ObjC<->Javascript interface.

There's another possibility for redoing the exec() stuff that doesn't use a
UIWebView. The code that the whitelist stuff uses provides another avenue
for communication from JS->ObjC. If you fire off an ajax request, you get a
chance to deny it and see the URL, just like with the UIWebViewDelegate
stuff, but it doesn't use an iframe. I'm not totally sure if this will fix
your problem though.

I've start to implement this ajax/URL based approach here:
https://github.com/mschulkind/phonegap-iphone/tree/url_exec
It's by no means complete, and based off a bit older of a phonegap tree, but
it should give you a great starting point if you want to pursue this.
This commit in particular has pretty much all of it:
https://github.com/mschulkind/phonegap-iphone/commit/f0900c89aff63d45fea2bdfc23ac703c98b9e4df

Now, here are the problems I've had:
1) Outstanding UIWebViewDelegate loadRequest... calls block cellForRow...
UITableViewDelegate calls. This is a huge problem when the user is dragging
a table view (or other component most likely) and the run loop turns to
tracking mode, which does not execute UIWebViewDelegate calls for whatever
reason. The table view delegate calls normally fire in tracking mode, as
they should, but for whatever reason if there's an outstanding web view
delegate call, the table view doesn't fire until the web view one runs
(until the user stops dragging).

This means that as long as the user is dragging the table view and there's
an outstanding web view delegate call, the table view doesn't update at all.
You just get background color and no rows. I worked around this by using
dispatch_async() for any queue flushes in cellForRow..., which causes all
sorts of other subtle UI problems.

2) Now this was the huge kicker that sent me over the edge. I've spent 2
weeks trying to track down a HUGE memory leak that I've been having in my
app. My only conclusion is that some complex set of events makes the
UIWebView leak memory in javascript land left and right, and only on the
device, not the simulator. It leaks enough memory that my app crashes from
OOM after loading 5-10 new windows. I finally switched to SpiderMonkey for
my javascript and all the leaks went away, as well as the cellForRow
problem.

On Tue, Oct 25, 2011 at 5:46 PM, Becky Gibson <gibson.becky@gmail.com>wrote:

> On further testing it only seems to be happening on iOS 5 devices.  Has
> anyone else seen this?  Thus, it probably isn't related to the changes to
> queuing commands.   But, is certainly driving me crazy!
> -becky
>
>
> On Oct 25, 2011, at 4:51 PM, Becky Gibson wrote:
>
> > The notorious Mobile Safari innerHTML bug seems to be rearing its ugly
> head again.  Jesse or Shaz implemented this type of fix in PhoneGap:
> http://blog.techno-barje.fr/post/2010/10/06/UIWebView-secrets-part3-How-to-properly-call-ObjectiveC-from-Javascript
> .
> >
> > However, I think our new queuing mechanism may have broken that.  We do
> create an iframe and set gap://"ready" to trigger reading the commands from
> the queue. However, we always use the same iframe and don't delete and
> recreate it.  I'm not sure if that is the problem or if it is because we are
> now "pulling" the commands from objective-C rather than "pushing" them in
> through the iframe.src.
> >
> > This bit me because I thought some of my functionality wasn't working.
>  In cases where I was using innerHTML to write to the page in my success
> callback I was seeing nothing.   I had to debug to see that my methods were
> in fact returning success (and a well placed alert in the callback helped as
> well).
> >
> > We really need those automated UI tests to try and catch stuff like this.
> >
> > -becky
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message