ASP.NET viewstate crashes iPad browser

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 RA开发者_StackOverflow中文版M 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?

It sure sounds like a bug in Safari on iPad.

That said, that is an awful lot of viewstate. Do you actually need ANY of it?

A big mistake, in my opinion, was MS' decision to enable all viewstate by default. That means that if you change the background color of a textbox in a postback, the control "remembers" it's new background color afterwards, without you doing anything at all to make it happen. Less crudely put, it means you get a programming model a bit more like for a Windows Forms application, and it's all very easy for you, the developer.

But there is a price to pay. A web application is a client-server application. It's fundamentally different from an app running locally, and perhaps the programming model really shouldn't be the same in both cases...

If you don't know if you actually need viewstate, try disabling it for the whole page. If you find you need it for some specific control(s), disable it for all other controls, enable it for the control(s) that must have it, and enable it for the page again. I think you'll find most if not all of your vast amounts of viewstate isn't actually being used anyway - for anything other than eating up bandwidth that is.

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.

Methinks it's time to make the switch to ASP.Net MVC with jQuery AJAX.