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 21:36:31 GMT
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 <gibson.becky@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

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