iOS 5 Safari JavaScript execution exceeded timeout

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").

iPad 2, iOS 5, Safari

Posted on Oct 24, 2011 9:33 AM

Reply
19 replies

Oct 26, 2011 2:22 PM in response to illvminatvs

Yes, we are experiencing the same problem. Our HTML5 application was running fine until iOS 5. The error is occurring on both the iPhone and iPad.


As you pointed out, once the error occurs the browser is broken until it is restarted. Even Apple's HTML5 demos (http://developer.apple.com/safaridemos/) fail to execute once the error condition happens.


We are working on documenting a reproducible test case.

Oct 31, 2011 8:52 AM in response to illvminatvs

It appears that navigator.geolocation.watchPosition() is particularly notorious in causing this problem.

http://stackoverflow.com/questions/7855497/javascript-execution-exceeded-timeout


We did a quick check and by replacing handling position change notifications with timeout-based polling made this problem very-very hard to preproduce.


Still, it's a work around the bug that needs to be fixed in iOS5 Safari.

Dec 15, 2011 4:26 AM in response to Reluctant JavaScripter

I am using Dreamweaver's Mobile Starter page to do a mobile page. I am getting the exceeded time out on my iPhone 4S. Can you tell me how to do your work around?


Using this:

<link href="jquery.mobile-1.0a3.min.css" rel="stylesheet" type="text/css"/>

<script src="jquery-1.5.min.js" type="text/javascript"></script>

<script src="jquery.mobile-1.0a3.min.js" type="text/javascript"></script>


Thanks so much.

Jan 5, 2012 10:09 AM in response to pmweb9873

I advise against jumping on the "bug" bandwagon. Too often, people assume since one or two other people report the same thing, it must be an OS bug that only Apple can fix. Then they sit on their hands and wait. And wait. And wait. No fix ever comes from Apple and the rest of the world proceeds as if the "bug" doesn't even exist. <hint, hint>


I use Safari very heavily on complex sites with my iPad1. I've never seen this error. Remember that you are running on a mobile device with a constrained processor and RAM.

Jan 5, 2012 12:05 PM in response to etresoft

I stand corrected: I signed up for dev prgram free of charge, and meanwhile my colleague saw this exchange and he reminded me that he has submitted the bug quite some time ago. I could not access it because it looks like Apple bug reports are not accessible to others. That's the reason contirubters to this thread had no way of seeing the bug having already been reported.

Jan 5, 2012 12:33 PM in response to Reluctant JavaScripter

Just don't assume "the bug" actually exists. From your description, it sounds like you are triggering Safari's protection against out-of-control Javascript. For reasons of 3g bandwidth, CPU, and battery life, I'm sure those limits are much lower than on a desktop browser. Even if it is a bug, who is affected? In what way? If you were Apple, how would you prioritize this issue? In short, whatever you are waiting for may not happen for years, if ever. I suggest making your code more efficient. That is the only part of the equation you control.

Jan 5, 2012 2:09 PM in response to etresoft

It is definitely a bug in Safari. It occurs quasi-randomly and then puts Safari's JS engine in a corrupted state where all JS code will not execute regardless of the page it is running on. That means, when this bug occurs, even if you close the page that triggered the bug and then go to another page, let's say google.com, then you will receive the same exception. You must then forcefully quit Safari and open it back up again in order for JS to properly execute. You *could* chunk your code, but you'd have to chunk everything and break it up into so small of a chunks that *every* function call would have to be wrapped in a setTimeout and the body of that function would need helpers. Sometimes even simple DOM queries in jQuery like $('.foo') would trigger this behavior.


Now, I have gone back and refactored code a bit and there have been two incremental iOS releases so I haven't seen this bug since late October/early November. I could not pinpoint any part of my code which would trigger this issue and my only guess was that it could be caused by calling window.setInterval() but never clearing the interval in the callback function. But that seems rather far fetched. Not to mention doesn't really make sense.


Regardless, the issue (if it hasn't been address in an incremental release) is pretty serious because it affects the browser as a whole rather than just the page that has the slow running code. Meaning, if the user ever stumbles upon a page which triggers this bug then Safari will no longer execute JS on any page at all until it is restarted.


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.


So call it what you will. I'll call it a bug.

Jan 5, 2012 4:23 PM in response to illvminatvs

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.

Jan 5, 2012 4:41 PM in response to etresoft

etresoft wrote:



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.

Fine. Something as simple as


for(var i = 0; i < 30; i++);


If a JS engine can't increment an integer by 1, 30 times, without crashing there is something terribly wrong.



etresoft wrote:



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.


You're write to doubt this. I'm wrong to assume the issue didn't exist since at the time of posting this thread I was running the same program on:

  • iPad with iOS4
  • iPad with iOS5
  • iPad2 with iOS4
  • iPad2 with IOS5


Yet the bug would only occur on the last device.


No one has said that they refuse to try to work around this issue. This initial point of this thread was to find a potential solution, not complain about it. Truly, I haven't found *the* solution because I haven't pinpointed *the* problem. Whatever I have done between now and then has made the issue go away. However, when it did pop up, there was *no* work around. The browser was in a faulted state its engine would not execute any non-overly trivial code without being restarted.


I would be very interested in finding out exactly what piece of code was causing so that it could be avoided in the future or so that this bug could be reliably recreated. Unfortunately, this was not the case. I could not reliably recreate this bug nor find the code which was causing it. When it happened it would happen at random points in the program. Sometimes it would happen immediately, othertimes it would happen an hour after continual use. Never in the same place.


I find it very add that instead of contributing anything useful to the discussion you find it best to stay on your porch and scream :"just fix your code" (even though there is no place to pinpoint a problem) and "get off my lawn."

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

iOS 5 Safari JavaScript execution exceeded timeout

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.