ASP.NET viewstate приводит к сбою браузера iPad

Question

Сайт, над которым я работаю, имеет страницу веб-форм ASP.NET, на которую отправляются сообщения, и имеет около 88 КБ несжатого ViewState. Да, я понимаю, что это много ViewState. Я заметил, что любые посты обратно приводят к сбою браузера iPad и переходу на домашний экран iPad. Любые другие ссылки на странице работали нормально, хотя. Обратная связь работала нормально на iPhone 4. Когда я уменьшил ViewState на странице примерно до 48 КБ, проблема сбоя исчезла.

Это единственная похожая ссылка на эту проблему, которую я обнаружил http://www.devcomments.com/GWT-Obfuscation-crashes-iPad-Safari-browser-at1047668.htm, хотя она не относится к GWT и не ViewState.

Есть ли какое-то конкретное ограничение, вызванное где-то в связи с этой проблемой, или это просто недокументированная ошибка в браузере iPad?

EDIT: После того, как у меня появилось еще немного времени на iPad, и он кое-что прочитал в Интернете, кажется, что ОС закрывает Safari, если чувствует, что Safari оскорбляет его. ОС либо считает, что Safari использует слишком много ОЗУ или слишком много ЦП, я не уверен, что именно в случае этой проблемы Viewstate. Я столкнулся с еще одной проблемой сбоя, когда Viewstate вообще отсутствует, но сбой регулярно происходит после небольшого XHR, по-видимому, когда работает какой-то Javascript, но его трудно определить. Во втором случае отключение Javascript предотвращает сбой Safari, но также делает страницу бесполезной.

Так что я думаю, что мой вопрос по-прежнему состоит в том, каковы действительные ограничения в iPad 1 Safari и как люди тестируют эти ограничения на сбой?

Answer 1

Это похоже на ошибку в Safari на iPad.

Тем не менее, это очень большое количество просмотров.Вам на самом деле это нужно?

Большой ошибкой, на мой взгляд, было решение MS включить все viewstate по умолчанию.Это означает, что если вы изменяете цвет фона текстового поля в обратной передаче, элемент управления «запоминает» его новый цвет фона впоследствии, и вы ничего не делаете, чтобы это произошло.Менее грубо говоря, это означает, что вы получаете модель программирования немного больше похожую на приложение Windows Forms, и это все очень просто для вас, разработчика.

Но за это приходится платить.Веб-приложение - это клиент-серверное приложение.Он принципиально отличается от приложения, работающего локально, и, возможно, модель программирования действительно не должна быть одинаковой в обоих случаях ...

Если вы не знаете, действительно ли вам нужно представление состоянияпопробуйте отключить его для всей страницы.Если вы обнаружите, что он вам нужен для какого-то определенного элемента (ов), отключите его для всех остальных элементов управления, включите его для элемента (ов), который должен иметь его, и снова включите для страницы.Я думаю, вы обнаружите, что большинство, если не все ваши огромные данные, фактически не используются в любом случае - ни для чего, кроме как поглощение пропускной способности.

Answer 2

Проблема заключается в том, что когда публикуется слишком много контента формы, например, огромного Viewstate, Safari закрывается iOS за использование слишком большого количества ресурсов или отсутствие ответа во времени. Я не эксперт по iOS, но это не проблема Viewstate, а проблема iOS / Safari в целом.

Answer 3

Думаю, пришло время переключиться на ASP.Net MVC с помощью jQuery AJAX.