ASP.NET AJAX回发突然停在IPhone / iPad的 [英] ASP.NET Ajax postback suddenly stops on IPhone/IPad

问题描述

我有一个使用更新面板和一些按钮的Asp.Net 4.0网站/控制接口。更新面板被连接到该执行每5秒，导致局部回传计时器。按钮切换一些设置，然后通过类似这样的调用强制更新面板的更新：

I have an Asp.Net 4.0 website/control interface that uses an update panel and some buttons. The update panel is wired to a timer that executes every 5 seconds, causing a partial postback. The buttons toggles some settings and then forces an update of the update panel through a call similar to this:

var prm = Sys.WebForms.PageRequestManager.getInstance();
prm._doPostBack('<%= UpdatePanel.ClientID %>', '');
return true;

该网站运行正常的IE / Firefox和Safari浏览器上的移动设备（IPhone / iPad的），但在移动设备上的回传随机默默停止工作。我想这个的可以的有节省电池做的，当它空闲时关闭Safari浏览器的局部回传了下来。问题是，当用户返回到该站点回传被完全切断，并既不计时器也不按钮导致任何回发没有更多。 （我有监控网络流量的服务器上验证这一点）。甚至当用户刷新网站（多次）的局部回传回来发挥作用。它只是停止发布数据到服务器。然后突然和回传再次开始工作没有特别的理由。停机时间往往长达10分钟，这完全使我的网站不能用于其目的。

The site runs fine on IE/Firefox and on Safari mobile devices (IPhone/IPad) but on the mobile devices the postback randomly and silently stops working. I figure this may have to do with saving batteries and that safari shuts the partial postback down when its idle. The problem is that when the user returns to the site the postback is completely shut off and neither the timer nor the buttons causes any postbacks no more. (I have monitored the network traffic on the server to verify this). Not even when the user refreshes the website (multiple times) the partial postback comes back into play. It just stops posting data to the server. Then suddenly and for no particular reason the postback starts working again. The downtime is often up to 10 minutes, which completely renders my website useless for its purpose.

由于需要很长时间回传重新开始我不知道是否有在任的客户端，或在IIS中的任何设置玩？之前

Given that it takes so long before the postback starts again I wonder if there are any settings on either client side or in IIS to play with?

该网站将在我的客户的设备只能运行，它不是公开的，所以如果有任何设置与客户端上，我为它玩了。

The website will run only on my customers devices, its not public, so if there is any settings to play with on the client I am up for it.

我真搞不清楚这一点，还没有找到一种方法来触发虫，它只是有时会发生。任何建议和提示是多少AP preciated。

I am really confused about this and haven't found a way to trigger the "bug", it just happens sometimes. Any advices and tips are much appreciated.

更新：

增加了一些错误处理，我有（没有一致）时，回发失败，收到以下消息：

Added some error handling and I have (not consistently) receive the following message when the postback fails:

该页面正在执行异步回发，但ScriptManager.SupportParialRendering属性设置为false。确保属性回发期间设置为true。

The page is performing an async postback but the ScriptManager.SupportParialRendering property is set to false. Ensure that the property is set to true during postback.

Odly足够此属性是在一审的装置显然是真的，否则回发永远不会成功，这是不是这样的。

Odly enough this property is obviously true for the device in the first instance, otherwise the postback would never work, which is not the case.

更新2：
发现folloing博客文章暗示来改变browserCap web.config中设置。现在尝试此。将报告。其他建议仍然值得欢迎。
ASP.NET 4的browserCaps（或：他们在想什么？）

以上禁用JavaScript的在全屏模式下的Safari移动（从主屏幕运行）。以下文章建议对这个问题的修复程序。
疑难杂症：iPad上与ASP.NET

The above disables javascript in safari mobile in fullscreen mode (running from home screen). The following article suggests a fix on this issue. Gotcha: iPad versus ASP.NET

推荐答案

在我的问题更新2下的结果解决了这个问题。显然，Safari浏览器UserAgents偶尔公认的Mozilla 0.0，如下面的博客文章标识： ASP .NET 4的browserCaps（或：他们在想什么？）：

The findings under "update 2" in my question solves the issue. Apparently the Safari UserAgents occasionally recognized as Mozilla 0.0, as identified in the following blog post: ASP.NET 4 BrowserCaps (or: what were they thinking?):

第一个跆拳道是，如果它检测到，根据的browserCaps不支持异步回发一个浏览器的异步回发的.NET框架实际上抛出异常。这是因为如果他们认为他们知道谁能够异步回发的，甚至以压倒性的相反证据最好...

The first WTF is that the .NET framework actually throws an exception if it detects an async postback from a browser that according to BrowserCaps does not support async postback. It’s as if they think they know best who is capable of async postbacks even with overwhelming evidence to the contrary…

接下来的WTF基本上很难找到。为什么Safari浏览器UserAgents偶尔公认的Mozilla 0.0，为什么使用我刚刚从异常抄的UserAgent字符串时，是我从来没有能够重现，即使这个问题？

The next WTF was substantially harder to find. Why are Safari UserAgents occasionally recognized as Mozilla 0.0 and why was I never able to reproduce the issue even when using a UserAgent string that I just copied from an exception?

答案就在

＆LT;的browserCaps userAgentCacheKeyLength =64/＆GT;

对于用户代理缓存密钥长度的默认设置是采取的UserAgent字符串的前64个字符。 ...

The default setting for the user agent cache key length is to take the first 64 characters of the UserAgent string. ...

和进一步下跌的页面：

在userAgentCacheKeyLength设置为256解决了这个问题，尽管仍有串的UserAgent那里被识别为Mozilla的0.0。至少现在是一致的。

Setting the userAgentCacheKeyLength to 256 solved the problem, even though there are still UserAgent strings out there that are identified as Mozilla 0.0. At least now it’s consistent.

因此，把＆LT;的browserCaps userAgentCacheKeyLength =256/＆GT; Web.Config中解决这个问题

So, putting <browserCaps userAgentCacheKeyLength="256" /> in Web.Config solves the issue.

这不幸导致另一个问题，当Safari浏览器全屏模式（链接保存在主屏幕上）被使用。在全屏模式下Safari使用不同的HTTP用户代理字符串，和ASP.NET已不识别浏览器如Safari，而是将其识别为无能力和例如JavaScript和JQuery的将停止工作的通用浏览器。在疑难杂症的进一步阐述：对iPad的ASP.NET 。解决的方法是把下面的Page_Init每个网站上。不是很优雅，但它与上面一起工作：

This unfortunately causes another problem when the safari browser is used in fullscreen mode (link saved on the home screen). In fullscreen mode Safari uses a different HTTP User Agent String, and ASP.NET doesn't anymore recognize the browser as Safari, instead it recognizes it as a generic browser with no capabilities and for example JavaScript and JQuery will stop working. The is further elaborated in Gotcha: iPad versus ASP.NET. The solution is to put the following in Page_Init on each website. Not very elegant, but it works together with the above:

protected void Page_PreInit(object sender, EventArgs e)
{
   if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparison.CurrentCultureIgnoreCase) > -1)
   {
      this.ClientTarget = "uplevel";
   }
}

这篇关于ASP.NET AJAX回发突然停在IPhone / iPad的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！