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('ctl00$LogoutButton','')">[ 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.
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:
…into the
<system.web>section of my web.config file, and also this: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:
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: