A site that I’m working on has a ASP.NET webforms page that posts back and had about 88KB of ViewState uncompressed. Yes, I realize that is a lot of ViewState. I observed that any post backs would cause the iPad browser to crash and go to the iPad home screen. Any other links on the page worked fine though. The post back worked ok on iPhone 4 as well. When I reduced the ViewState on the page to about 48KB the crashing problem went away.
This is the only at all similar reference to this issue that I’ve found http://www.devcomments.com/GWT-Obfuscation-crashes-iPad-Safari-browser-at1047668.htm though its not in reference to GWT and not ViewState.
Is there some specific limitation called out somewhere related to this issue or is it just an undocumented bug with the iPad browser?
EDIT:
After having some more time with an iPad, and reading some things online, it seems that the OS shuts down Safari if it feels that Safari is being abusive. The OS either thinks Safari is using too much RAM or too much CPU, I’m not sure which in the case of this Viewstate issue. I another crashing issue where there is no Viewstate at all but the crashing regularly occurs after a small XHR, seemingly when some Javascript is running but its difficult to tell. In the 2nd case disabling Javascript prevents Safari from crashing, but also makes the page useless.
So I guess my question is still what the actual restrictions are in iPad 1 Safari and how are people testing against these crashing restrictions?
The issue is that when there is too much form content being posted, like a huge Viewstate, Safari gets closed by iOS for using up too much resource or not responding in time. I’m not an iOS expert, but its not specifically a Viewstate issue, its an iOS/Safari issue in general.