Question

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;

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.

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.

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.

---

Update:

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

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 enough this property is obviously true for the device in the first instance, otherwise the postback would never work, which is not the case.

---

Update 2:
Found the folloing blog post suggesting to change the browserCap setting in web.config. Trying this now. Will report back. Other suggestions are still much welcomed.
ASP.NET 4 BrowserCaps (or: what were they thinking?)

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

Answer 1

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?):

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…

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?

The answer lies in

<browserCaps userAgentCacheKeyLength="64" />

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

And further down the page:

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.

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

---

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";
   }
}