I have a fairly large HTML/JS/CSS application that works great when running as a web application with Safari on the iPhone.

When running this same application in an UIWebView within a native iPhone application calls within jQuery to create HTML fragments fail silently (ie: $("<div>HELLO WORLD</div>"); will not create the element.

I've tracked this down to the following equivalent code snippet in clean jQuery method:

var div = document.createElement(“div”); div.innerHTML = “<div>HELLO WORLD</div>”;

When I look at div.outerHTML I see <div>/<div>

div.innerHTML returns an empty string.

This does not appear to be a jQuery problem, nor does this happen 100% of the time. I haven’t been able to find a pattern, but in some cases it works 2-3 times in a row, sometimes if fails 5-6 times consecutively. This seems to only shows up when running the application inside a UIWebView in an Objective-C application. Also I’ve only seen this on an actual device running iOS 4.2, not the emulator.

Has anyone run into anything similar? Does anyone have a fix?

I have a fairly large HTML/JS/CSS application that works great when running as a web application with Safari on the iPhone.

When running this same application in an UIWebView within a native iPhone application calls within jQuery to create HTML fragments fail silently (ie: $("<div>HELLO WORLD</div>"); will not create the element.

I've tracked this down to the following equivalent code snippet in clean jQuery method:

var div = document.createElement(“div”); div.innerHTML = “<div>HELLO WORLD</div>”;

When I look at div.outerHTML I see <div>/<div>

div.innerHTML returns an empty string.

This does not appear to be a jQuery problem, nor does this happen 100% of the time. I haven’t been able to find a pattern, but in some cases it works 2-3 times in a row, sometimes if fails 5-6 times consecutively. This seems to only shows up when running the application inside a UIWebView in an Objective-C application. Also I’ve only seen this on an actual device running iOS 4.2, not the emulator.

Has anyone run into anything similar? Does anyone have a fix?

• javascript
• iphone
• jquery
• uiwebview

3 Answers 3

I had this problems too. It happens when the CPU of the phone is very busy (say 100%). Then the rendering engine sometimes forget about innerHTML settings.

The solution included in my unify project is to test if there is an element in childNodes, otherwise apply it again.

var target = document.createElement("div");
var text = "<div>Hello World</div>";
target.innerHTML = text;
var self = this;
self.__intervalHandle = window.setInterval(function() {
  target.innerHTML = text:
  if (target.firstChild) {
    window.clearInterval(self.__intervalHandle);
    self.__intervalHandle = null;
  }
}, 100);

This forces the rendering engine to apply the innerHTML to the DOM and gives the rendering engine some time (100 ms in this example, a good value in our tests) to handle it.

Well, the solution [NOT a production quality solution] posted by Sebastian worked, but I couldn’t confirm if CPU load would cause this issue. I generated a lot of background load on the iOS host and couldn’t reproduce this issue.

Upon further investigation, the rendering issue seems to be a side effect of iOS shell canceling the navigation. Once the navigation is canceled by the iOS shell, the rendering engine probably take that as not needing to render more UI [basically doesn’t render anything for a small period].

One way to fix this would be to send mands to iOS shell as hash (#) parameters instead of a URL. This way iOS shell will get the mands and doesn’t need to cancel the navigation. This approach seems to work in the test code below. So, if window.location is set to location1, it alerts “At: 1” and element e2 has no value. And if the window.location is set to location2, it alerts “At: 0” and element e2 has the value.

@Kevin, could you confirm that you were canceling the navigation on iOS host when this behavior happened.

Test Code:

Javascript:

    var location1 = "myApp://Test";
    var location2 = "#myApp://Test";
    $("#change").live("click", function (e) {
        var element = document.getElementById("e1");
        window.location = location1; var i = 0;            
        element.innerHTML = "At: " + i;
        window.__intervalHandle = window.setInterval(function () {
            var html = element.innerHTML;
            if (html) {
                 alert(html);
                window.clearInterval(window.__intervalHandle);
                window.__intervalHandle = null;
            } else {
                element.innerHTML = "At: " + ++i;
            }
        }, 1);
        document.getElementById("e2").innerHTML = "Test";
    });

iOS pseudo code:

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
NSURL* u = [ request URL];

if( [[u scheme] pare:@"myapp" ] == NSOrderedSame) {
{ 
return NO; // don’t navigate
}
return YES; // navigate
}

You should take a look at http://blog.techno-barje.fr/post/2010/10/06/UIWebView-secrets-part3-How-to-properly-call-ObjectiveC-from-Javascript.

It turns out that cancelling navigation as part of the -webView:shouldStartLoadWithRequest: delegate method may cause issues with innerHTML. I updated our JS code to use the method remended in that article and I haven't seen the innerHTML issue crop up in a while.