Safari on iPad occasionally doesn't recognize ASP.NET postback links

Question

I'm having a really hard time pinpointing the source of an intermittent problem in an ASP.NET web application running on the Safari browser on a third-generation iPad running iOS 6.0. What happens is that, on occasion, the that <a> tags set up as hyperlinks that do postbacks via JavaScript will suddenly stop working and don't appear to do anything if you touch them on the screen. These include an asp:LinkButton control that is set up as a logout link, and the header row of a GridView that is set up to allowing row sorting. There seems to be no rhyme or reason behind it - they will work as normal for awhile, then stop, and I'll later notice that they start working again (mostly after closing Safari and re-opening it, though that doesn't always seem to work).

The logout control looks like this in the aspx file:

<asp:LinkButton ID="LogoutButton" onclick="LogoutButton_Click" runat="server">[ Logout ]</asp:LinkButton>

and appears as this in the resulting HTML:

<a id="LogoutButton" href="javascript:__doPostBack(&#39;ctl00$LogoutButton&#39;,&#39;&#39;)">[ Logout ]</a>

Is there anything special about Safari running on the iPad that might prevent such links to break on occasion, such as too much data loaded on the page or in other open browser tabs, or maybe something with the ViewState that is acting up in this scenario? Even after playing around with the web application on the iPad for awhile, I can't find any particular way to recreate the problem, so I can't even begin to try to fix it which is really frustrating, so I'm looking for guidance from those who have developed ASP.NET apps and know the iPad and/or Safari environments really well. I've never had this problem occur on a desktop browser.

Update: Using the trick outlined on this page about how to add a pseudo-View Source option to Safari on the iPad, I have now been able to see the difference in the generated HTML of a page where the postback links are working, and a page where it's stopped. In short, the __doPostBack JavaScript function that ASP.NET normally imbeds in the page... simply stops getting imbedded for some reason. As a result, the JavaScript tied to the links simply error out. Here's what ASP.NET normally adds to the page to get the postback links working:

<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['form1'];
if (!theForm) {
    theForm = document.form1;
}
function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();
    }
}
//]]>
</script>

This appears to be the same issue described on the Apple support forum and here on SO. The latter suggests that ASP.NET may sometimes be failing to recognize Safari on the iPad as being JavaScript capable and thus doesn't properly insert the __doPostBack function into the page. Other JavaScript on my page is still working fine, though, so it doesn't fully explain my problem.

Solution

After finding this question on Stack Overflow with virtually the same problem, I ran the browserCaps output page suggested by Stephen and found that Safari, when run in full screen mode from a link on the iPad's home screen, appeared to our ASP.NET server as a generic, no capability browser. I applied the fix suggested by Avada Kedavra in that other question, which entailed putting this:

<browserCaps userAgentCacheKeyLength="256" />

...into the <system.web> section of my web.config file, and also this:

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

in the code behind file for the main web page that was acting up. Jason Kealey, the source of that other person's fix, also suggests in the comments section of his findings that it might also be helpful to add this to a .browser file in the App_Browsers folder of your ASP.NET web application:

<browsers>
  <browser refID="Mozilla" >
    <capabilities>
      <capability name="cookies"  value="true" />
      <capability name="type" value="Uplevel" />
    </capabilities>
  </browser>

  <browser refID="Default">
    <capabilities>
      <capability name="cookies" value="true" />
      <capability name="type" value="Uplevel" />
    </capabilities>
  </browser>
</browsers>

Edit: I applied this fix to my application, but it broke other areas, specifically, it was identifying Chrome and Safari as "uplevel", which caused it to be detected in other areas as "IE". The code below makes this fix only apply to iDevices when not identified in the user agent as Safari:

string ua = Request.UserAgent;
if (ua != null
    && (ua.IndexOf("iPhone", StringComparison.CurrentCultureIgnoreCase) >= 0
    || ua.IndexOf("iPad", StringComparison.CurrentCultureIgnoreCase) >= 0
    || ua.IndexOf("iPod", StringComparison.CurrentCultureIgnoreCase) >= 0)
    && ua.IndexOf("Safari", StringComparison.CurrentCultureIgnoreCase) < 0)
{
    this.ClientTarget = "uplevel";
}

Comments

[Stephen]

Maybe you were on the right track with the UA string and getting the wrong browser caps. What version of .NET are you using? .NET 1.x was horrendous at identifying anything other than IE. 2.x (up through 3.5) wasn't very good either. They actually made some good progress with 4.0, and they can identify some mobile devices as such (I think all iOS devices are identified as iPhone). My next step would be to copy the code here slingfive.com/pages/code/browserCaps/… and browse there from your server using your iPad to see what browser they think you're using.

[Derek]

It's a .NET 4.0 app. I put the browser caps dump for Safari on the iPad on pastebin, if you're curious. I don't see anything that immediately jumps out at me as what might be causing the problem. The Platform is "Unknown," but that doesn't necessarily explain why the JavaScript works some times and not others.

[Derek]

Hmm, I seem to have found another person with the same exact problem, and I have noticed that my problem often starts after the application starts up in full screen mode from a home screen link. I'm investigating further.

[Derek]

Looks like the fix suggested in the link I listed above worked! Checking the browser caps info for when my app stopped working produced the listing you can see here on pastebin. Stephen, thanks again for your help - I upvoted your suggestion about checking the browser caps since it led me to the right answer, but I'll sum up my solution in a different answer, since it ultimately wasn't related to the OutputCache.

[Kevin Vella]

Great ! This worked for me :) My pagination for a listview was not working. Applied the web.config and pagepreinit fix and now its working. Thanks a million!

[Rehan Parvez]

@Derek, I have tried this, it is not working for me, its Ispostback is always and doesnot pointing to the click event

[Derek]

@RehanParvez, since I posted this nearly four years ago, you may be running into a variation of this problem that isn't covered here, or something new altogether. You're more likely to solve your issue if you post a new question with the exact code you are using related to your problem.