You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2011/10/25 22:51:01 UTC
new iOS command queue may have broken innerHTML fix
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
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
SpiderMonkey is "available under MPL/GPL/LGPL tri-license." and it's just a
lib, so I think it should be covered fine with LGPL.
I'm still not totally sure how this could be merged into Callback proper
since it'll only work for my app and any others not using HTML.
On Fri, Oct 28, 2011 at 2:07 PM, Brian LeRoux <b...@brian.io> wrote:
> I'm all for this, I'd love to see this merged, way less of a hack and
> far bigger upside than using the url for transport. This is much
> closer to the Android implementation and, if ever iOS gets
> backgrounding some very cool possabilities open up. I'm curious, what
> is the licensing ramifications of this change?
>
>
>
>
> On Wed, Oct 26, 2011 at 1:42 PM, Matthew Schulkind <ms...@gmail.com>
> wrote:
> > Another huge benefit of this that I forgot to mention is that this allows
> > for running JS on a non-GUI thread, so you can run calculations, etc.
> > without blocking the UI, but it's definitely going to be tricky to take
> full
> > advantage of this.
> >
> > On Wed, Oct 26, 2011 at 4:38 PM, Matthew Schulkind <mschulkind@gmail.com
> >wrote:
> >
> >> Here's what I've done to phonegap:
> >> https://github.com/mschulkind/phonegap-iphone/tree/spidermonkey
> >>
> >> I'm using iMonkey for the SpiderMonkey port:
> >> https://github.com/couchbaselabs/iMonkey
> >> Right now, I can only get iMonkey working on the device, not the
> simulator,
> >> but I'm sure it's possible with some work. It just crashes without a
> good
> >> stack trace on the simulator.
> >>
> >> Here's the glue code that I've written so far:
> >> https://github.com/mschulkind/sm-bridge
> >> It would take a little work to integrate this into your own stuff, but
> >> should give you a pretty good idea of what's going on.
> >>
> >> SpiderMonkey is purely a JS environment, so it doesn't have DOM etc. and
> >> you'll see that I rewrote the Interval/Timeout stuff as well as some
> event
> >> stuff, and I had to write an HTTP plugin since there's no XHR built in
> >> either.
> >>
> >> All that said, the main challenge for using this for Callback in general
> is
> >> that there's no HTML type display, and the only HTML display that Apple
> >> allows is UIWebView, so I'm not sure how you'd use this on a Callback
> >> project that does the typical HTML5/CSS approach.
> >>
> >>
> >> On Wed, Oct 26, 2011 at 4:27 PM, Brian LeRoux <brian.leroux@nitobi.com
> >wrote:
> >>
> >>> Matthew --- this is really interesting work. Where can I have a look
> >>> at your Spidermonkey stuff? Think its a very compelling route.
> >>>
> >>>
> >>>
> >>> On Wed, Oct 26, 2011 at 9:53 AM, Matthew Schulkind <
> mschulkind@gmail.com>
> >>> wrote:
> >>> > I've now run just about all of my code (including phonegap) under V8
> >>> (using
> >>> > chrome for the developer tools), WebKit, and now SpiderMonkey with no
> >>> > changes other than adding the missing bits where appropriate (like
> >>> > setTimeout/Interval and XHR for SpiderMonkey).
> >>> >
> >>> > What problems would you think would exist?
> >>> >
> >>> > On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <as...@gmail.com>
> wrote:
> >>> >
> >>> >> I meant in general, rather than specific to the ObjC<->JS bridge.
> >>> >>
> >>> >> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
> >>> >>
> >>> >> > I was using only UIWebView and had the previously mentioned
> problems.
> >>> Now
> >>> >> I
> >>> >> > ripped out UIWebView completely and I'm only using SpiderMonkey
> and
> >>> >> having
> >>> >> > none of the previously mentioned problems.
> >>> >> >
> >>> >> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com>
> >>> wrote:
> >>> >> >
> >>> >> >> You're using Webkit + Spidermonkey? Isn't that just asking for
> >>> massive
> >>> >> >> compatibility headaches?
> >>> >> >>
> >>> >> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
> >>> >> >>
> >>> >> >>> 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.
> >>> >> >>
> >>> >> >>
> >>> >>
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Brian LeRoux <b...@brian.io>.
I'm all for this, I'd love to see this merged, way less of a hack and
far bigger upside than using the url for transport. This is much
closer to the Android implementation and, if ever iOS gets
backgrounding some very cool possabilities open up. I'm curious, what
is the licensing ramifications of this change?
On Wed, Oct 26, 2011 at 1:42 PM, Matthew Schulkind <ms...@gmail.com> wrote:
> Another huge benefit of this that I forgot to mention is that this allows
> for running JS on a non-GUI thread, so you can run calculations, etc.
> without blocking the UI, but it's definitely going to be tricky to take full
> advantage of this.
>
> On Wed, Oct 26, 2011 at 4:38 PM, Matthew Schulkind <ms...@gmail.com>wrote:
>
>> Here's what I've done to phonegap:
>> https://github.com/mschulkind/phonegap-iphone/tree/spidermonkey
>>
>> I'm using iMonkey for the SpiderMonkey port:
>> https://github.com/couchbaselabs/iMonkey
>> Right now, I can only get iMonkey working on the device, not the simulator,
>> but I'm sure it's possible with some work. It just crashes without a good
>> stack trace on the simulator.
>>
>> Here's the glue code that I've written so far:
>> https://github.com/mschulkind/sm-bridge
>> It would take a little work to integrate this into your own stuff, but
>> should give you a pretty good idea of what's going on.
>>
>> SpiderMonkey is purely a JS environment, so it doesn't have DOM etc. and
>> you'll see that I rewrote the Interval/Timeout stuff as well as some event
>> stuff, and I had to write an HTTP plugin since there's no XHR built in
>> either.
>>
>> All that said, the main challenge for using this for Callback in general is
>> that there's no HTML type display, and the only HTML display that Apple
>> allows is UIWebView, so I'm not sure how you'd use this on a Callback
>> project that does the typical HTML5/CSS approach.
>>
>>
>> On Wed, Oct 26, 2011 at 4:27 PM, Brian LeRoux <br...@nitobi.com>wrote:
>>
>>> Matthew --- this is really interesting work. Where can I have a look
>>> at your Spidermonkey stuff? Think its a very compelling route.
>>>
>>>
>>>
>>> On Wed, Oct 26, 2011 at 9:53 AM, Matthew Schulkind <ms...@gmail.com>
>>> wrote:
>>> > I've now run just about all of my code (including phonegap) under V8
>>> (using
>>> > chrome for the developer tools), WebKit, and now SpiderMonkey with no
>>> > changes other than adding the missing bits where appropriate (like
>>> > setTimeout/Interval and XHR for SpiderMonkey).
>>> >
>>> > What problems would you think would exist?
>>> >
>>> > On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <as...@gmail.com> wrote:
>>> >
>>> >> I meant in general, rather than specific to the ObjC<->JS bridge.
>>> >>
>>> >> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
>>> >>
>>> >> > I was using only UIWebView and had the previously mentioned problems.
>>> Now
>>> >> I
>>> >> > ripped out UIWebView completely and I'm only using SpiderMonkey and
>>> >> having
>>> >> > none of the previously mentioned problems.
>>> >> >
>>> >> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com>
>>> wrote:
>>> >> >
>>> >> >> You're using Webkit + Spidermonkey? Isn't that just asking for
>>> massive
>>> >> >> compatibility headaches?
>>> >> >>
>>> >> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
>>> >> >>
>>> >> >>> 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.
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
Another huge benefit of this that I forgot to mention is that this allows
for running JS on a non-GUI thread, so you can run calculations, etc.
without blocking the UI, but it's definitely going to be tricky to take full
advantage of this.
On Wed, Oct 26, 2011 at 4:38 PM, Matthew Schulkind <ms...@gmail.com>wrote:
> Here's what I've done to phonegap:
> https://github.com/mschulkind/phonegap-iphone/tree/spidermonkey
>
> I'm using iMonkey for the SpiderMonkey port:
> https://github.com/couchbaselabs/iMonkey
> Right now, I can only get iMonkey working on the device, not the simulator,
> but I'm sure it's possible with some work. It just crashes without a good
> stack trace on the simulator.
>
> Here's the glue code that I've written so far:
> https://github.com/mschulkind/sm-bridge
> It would take a little work to integrate this into your own stuff, but
> should give you a pretty good idea of what's going on.
>
> SpiderMonkey is purely a JS environment, so it doesn't have DOM etc. and
> you'll see that I rewrote the Interval/Timeout stuff as well as some event
> stuff, and I had to write an HTTP plugin since there's no XHR built in
> either.
>
> All that said, the main challenge for using this for Callback in general is
> that there's no HTML type display, and the only HTML display that Apple
> allows is UIWebView, so I'm not sure how you'd use this on a Callback
> project that does the typical HTML5/CSS approach.
>
>
> On Wed, Oct 26, 2011 at 4:27 PM, Brian LeRoux <br...@nitobi.com>wrote:
>
>> Matthew --- this is really interesting work. Where can I have a look
>> at your Spidermonkey stuff? Think its a very compelling route.
>>
>>
>>
>> On Wed, Oct 26, 2011 at 9:53 AM, Matthew Schulkind <ms...@gmail.com>
>> wrote:
>> > I've now run just about all of my code (including phonegap) under V8
>> (using
>> > chrome for the developer tools), WebKit, and now SpiderMonkey with no
>> > changes other than adding the missing bits where appropriate (like
>> > setTimeout/Interval and XHR for SpiderMonkey).
>> >
>> > What problems would you think would exist?
>> >
>> > On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <as...@gmail.com> wrote:
>> >
>> >> I meant in general, rather than specific to the ObjC<->JS bridge.
>> >>
>> >> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
>> >>
>> >> > I was using only UIWebView and had the previously mentioned problems.
>> Now
>> >> I
>> >> > ripped out UIWebView completely and I'm only using SpiderMonkey and
>> >> having
>> >> > none of the previously mentioned problems.
>> >> >
>> >> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com>
>> wrote:
>> >> >
>> >> >> You're using Webkit + Spidermonkey? Isn't that just asking for
>> massive
>> >> >> compatibility headaches?
>> >> >>
>> >> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
>> >> >>
>> >> >>> 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.
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>>
>
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
Here's what I've done to phonegap:
https://github.com/mschulkind/phonegap-iphone/tree/spidermonkey
I'm using iMonkey for the SpiderMonkey port:
https://github.com/couchbaselabs/iMonkey
Right now, I can only get iMonkey working on the device, not the simulator,
but I'm sure it's possible with some work. It just crashes without a good
stack trace on the simulator.
Here's the glue code that I've written so far:
https://github.com/mschulkind/sm-bridge
It would take a little work to integrate this into your own stuff, but
should give you a pretty good idea of what's going on.
SpiderMonkey is purely a JS environment, so it doesn't have DOM etc. and
you'll see that I rewrote the Interval/Timeout stuff as well as some event
stuff, and I had to write an HTTP plugin since there's no XHR built in
either.
All that said, the main challenge for using this for Callback in general is
that there's no HTML type display, and the only HTML display that Apple
allows is UIWebView, so I'm not sure how you'd use this on a Callback
project that does the typical HTML5/CSS approach.
On Wed, Oct 26, 2011 at 4:27 PM, Brian LeRoux <br...@nitobi.com>wrote:
> Matthew --- this is really interesting work. Where can I have a look
> at your Spidermonkey stuff? Think its a very compelling route.
>
>
>
> On Wed, Oct 26, 2011 at 9:53 AM, Matthew Schulkind <ms...@gmail.com>
> wrote:
> > I've now run just about all of my code (including phonegap) under V8
> (using
> > chrome for the developer tools), WebKit, and now SpiderMonkey with no
> > changes other than adding the missing bits where appropriate (like
> > setTimeout/Interval and XHR for SpiderMonkey).
> >
> > What problems would you think would exist?
> >
> > On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <as...@gmail.com> wrote:
> >
> >> I meant in general, rather than specific to the ObjC<->JS bridge.
> >>
> >> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
> >>
> >> > I was using only UIWebView and had the previously mentioned problems.
> Now
> >> I
> >> > ripped out UIWebView completely and I'm only using SpiderMonkey and
> >> having
> >> > none of the previously mentioned problems.
> >> >
> >> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com>
> wrote:
> >> >
> >> >> You're using Webkit + Spidermonkey? Isn't that just asking for
> massive
> >> >> compatibility headaches?
> >> >>
> >> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
> >> >>
> >> >>> 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.
> >> >>
> >> >>
> >>
> >>
> >
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Brian LeRoux <br...@nitobi.com>.
Matthew --- this is really interesting work. Where can I have a look
at your Spidermonkey stuff? Think its a very compelling route.
On Wed, Oct 26, 2011 at 9:53 AM, Matthew Schulkind <ms...@gmail.com> wrote:
> I've now run just about all of my code (including phonegap) under V8 (using
> chrome for the developer tools), WebKit, and now SpiderMonkey with no
> changes other than adding the missing bits where appropriate (like
> setTimeout/Interval and XHR for SpiderMonkey).
>
> What problems would you think would exist?
>
> On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <as...@gmail.com> wrote:
>
>> I meant in general, rather than specific to the ObjC<->JS bridge.
>>
>> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
>>
>> > I was using only UIWebView and had the previously mentioned problems. Now
>> I
>> > ripped out UIWebView completely and I'm only using SpiderMonkey and
>> having
>> > none of the previously mentioned problems.
>> >
>> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com> wrote:
>> >
>> >> You're using Webkit + Spidermonkey? Isn't that just asking for massive
>> >> compatibility headaches?
>> >>
>> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
>> >>
>> >>> 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.
>> >>
>> >>
>>
>>
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
I've now run just about all of my code (including phonegap) under V8 (using
chrome for the developer tools), WebKit, and now SpiderMonkey with no
changes other than adding the missing bits where appropriate (like
setTimeout/Interval and XHR for SpiderMonkey).
What problems would you think would exist?
On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <as...@gmail.com> wrote:
> I meant in general, rather than specific to the ObjC<->JS bridge.
>
> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
>
> > I was using only UIWebView and had the previously mentioned problems. Now
> I
> > ripped out UIWebView completely and I'm only using SpiderMonkey and
> having
> > none of the previously mentioned problems.
> >
> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com> wrote:
> >
> >> You're using Webkit + Spidermonkey? Isn't that just asking for massive
> >> compatibility headaches?
> >>
> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
> >>
> >>> 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.
> >>
> >>
>
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Matt Kane <as...@gmail.com>.
I meant in general, rather than specific to the ObjC<->JS bridge.
On 26 Oct 2011, at 17:36, Matthew Schulkind wrote:
> I was using only UIWebView and had the previously mentioned problems. Now I
> ripped out UIWebView completely and I'm only using SpiderMonkey and having
> none of the previously mentioned problems.
>
> On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com> wrote:
>
>> You're using Webkit + Spidermonkey? Isn't that just asking for massive
>> compatibility headaches?
>>
>> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
>>
>>> 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.
>>
>>
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
I was using only UIWebView and had the previously mentioned problems. Now I
ripped out UIWebView completely and I'm only using SpiderMonkey and having
none of the previously mentioned problems.
On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <as...@gmail.com> wrote:
> You're using Webkit + Spidermonkey? Isn't that just asking for massive
> compatibility headaches?
>
> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
>
> > 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.
>
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Matt Kane <as...@gmail.com>.
You're using Webkit + Spidermonkey? Isn't that just asking for massive compatibility headaches?
On 25 Oct 2011, at 23:29, Matthew Schulkind wrote:
> 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.
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
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 <gi...@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
>
>
Re: new iOS command queue may have broken innerHTML fix
Posted by Becky Gibson <gi...@gmail.com>.
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
Re: new iOS command queue may have broken innerHTML fix
Posted by Patrick Mueller <pm...@gmail.com>.
Perhaps we need to go the android route, implement a minimal in-process HTTP
server, and XHR our messages from JS to ObjC.
On Tue, Oct 25, 2011 at 16:51, Becky Gibson <gi...@gmail.com> wrote:
> 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.
Have we tried with a lighter-weight element, like <img>? (setting the src
attribute). I'm always leering of using iframe's on mobile anyway, because
I believe you are limited to a small number of iframes on your page in the
first place - not that users should be using iframes for anything, but
still.
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.
>
Do you mean the new "fast" messaging? Seems like the problem is with the
signalling from the JS side to the ObjC side, not the data transfer.
--
Patrick Mueller
http://muellerware.org
Re: new iOS command queue may have broken innerHTML fix
Posted by Matthew Schulkind <ms...@gmail.com>.
I'm the author of the new command queue stuff.
While it's certainly possible that my code broke this, the only difference
that I know of in how I use the iframe is that I don't set src to a
different value each time, I just use the same URL each time (as you note).
Previously, the JSON+URL encoded command was set as the src, in the same
iframe, the same way. I doubt the 'pull' matters much because it's just
another writeJavascript: call like there is all over the place.
On Tue, Oct 25, 2011 at 4:51 PM, Becky Gibson <gi...@gmail.com>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