IOS 5 Safari JavaScript execution exceeded timeout

Question

I am working on a mobile web app that is primarily self-contained and communicated with the server only when necessary. Currently, the libraries being used are:
- jQuery 1.6.4
- jQuery UI 1.8.3
- Modified/patched version of jQTouch
Up until the release of iOS 5 we were also using touchscroll.js but it is no longer needed since Safari now supports position: fixed and native scrolling.
Since the release of iOS 5, seemingly at random, this exception is raised:
    JavaScript: Error undefined JavaScript execution exceeded timeout
Once it is raised, no JS code that runs for more than a *very* short period of time (say 1ms) will be executed by Safari. Refreshing the page, going to a new page, or going to a new domain has no effect. Any and all JS code, even something as simple as
    for(var i = 0; i < 30; i++) ;
will not be executed by the browser without the exception being raised. The only way around this is to force kill Safari and restart it. I suppose it is also possible to wrap any remotely "heavy duty" code in the application in a window.setTimeout(..., 1) or take advantage of Web Workers for everything but UI updates but that doesn't seem like a very good solution as the application is fairly large and it would require a substantial rewrite.
Has anyone encountered this issue before? How would you go about debugging something like this as it isn't any single piece of code that seems to put Safari into this broken state and it can happen seemingly at random?
I tried to figure out what the timeout of the JS engine is in mobile Safari by doing the following:
    var start, end;
    start = new Date();
    try {
       while(true);
    } catch (ex) {
      alert('test');
    end = new Date();
    console.log(Number(end) - Number(start) + 'ms');
Unfortunately it seems this timeout exception isn't a JS exception so it cannot be caught in a try/catch block; however, it appears the max timeout period is in the realm of several seconds. None of the code in our app locks the browser/JS engine for that long (as it would provide a terrible UX) and most if not all of it probably has a sub 300ms execution time (including anything that's "heavy duty").

Answer 1

illvminatvs wrote:
Sometimes even simple DOM queries in jQuery like $('.foo') would trigger this behavior.
There is nothing simple about jQuery. I'm pretty confident I could create a page where such a selector would bring any desktop browser to its knees.
Moreover, this issue did not exist in iOS 4 and only manifested itself in iOS 5 and IIRC only occured on iPad 2 devices and not the original iPad.
I highly doubt that.
So call it what you will. I'll call it a bug.
What I'll do is put on my overalls, grab my cane, and tell you how it was in my day.
Back in my day, every operating system had bugs. Every application running on them had bugs. You know what we did? Blame the vendor? Yep. Filed a bug report? Sure. Sit on our hands? Never! You know what we did? We "worked around it". There was no internet where someone would post just the lines of code we needed. There were no example apps. There was no open source. Somehow, we still got it working.
Just suppose, for the sake of argument, that you are absolutely correct. This is a bug the Apple introduced in iOS 5 and it breaks your app. Will Apple release a fix for it next month? Unlikely. Next quarter? Maybe, maybe not. 2015? My oldest Apple bug report is dated "04-Apr-2008 06:39 PM".
It is an imperfect, competitive world. If you don't want to work around the bugs, all that does is give that opportunity to someone else.