iOS 8 / Safari 8 not working with ASP.NET AJAX-Extensions

Asked 22/9, 2014 at 16:23 Answered 2/3, 2015 at 20:28

Our website suddenly stopped working when iOS 8 was rolled out. Every post-back from within an ASP.NET UpdatePanel leads to an empty page. It still works, if the user-agent is set to "Chrome" from within Safari 8 (on Mac).

I already tracked down, that some of the "ScriptResource.axd" and "WebResource.axd" files are not loaded at all. There is also an error telling "Sys.WebForms" is undefined (probably due to the missing script-files).

We are using ASP.NET 2.0 with AJAX-Extensions 1.0 (I know, quite outdated. But used to work or could be fixed until now).

Otway answered 22/9, 2014 at 16:23 Comment(1)

Wish I'd been able to find this post yesterday - I just came on to write up exactly the same thing. – Parted 25/9, 2014 at 9:54

Beware that this solution is only applicable to .NET version < 4.0

So here it is...

Working UA: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36

Not working UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.1.17 (KHTML, like Gecko) Version/7.1 Safari/537.85.10

The problem lies in the major version-change to AppleWebKit/600. ASP.NET AJAX does not correctly recognize the new Safari 8 browser (also with iOS 8). It thinks, that there is no support for partial-rendering. I found it in those lines from "PageRequestManager.cs":

bool supportsPartialRendering = (browser.W3CDomVersion >= MinimumW3CDomVersion) && (browser.EcmaScriptVersion >= MinimumEcmaScriptVersion) && browser.SupportsCallback;

MinimumEcmaScriptVersion/MinimumW3CDomVersion are both 1. Request.Browser gave me the following result:

W3CDomVersion = 1.0
EcmaScriptVersion = 1.0
SupportsCallback = false

Even though "EcmaScriptVersion" has a strange value, the problem is mainly caused by SupportsCallback beeing false.

The bug lies in the "mozilla.browser" file that ships with ASP.NET (located somewhere in "C:\Windows\Microsoft.NET"):

<browser id="Safari60" parentID="Safari">
  <identification>
    <capability name="appleWebTechnologyVersion" match="60" />
</identification>
<capture>
</capture>
<capabilities>
  <capability name="ecmascriptversion"       value="1.0" />
  </capabilities>
</browser>

<browser id="Safari85" parentID="Safari">
  <identification>
    <capability name="appleWebTechnologyVersion" match="85" />
  </identification>
  <capture>
  </capture>
  <capabilities>
    <capability name="ecmascriptversion"       value="1.4" />
  </capabilities>
</browser>

<browser id="Safari1Plus" parentID="Safari">
  <identification>
    <capability name="appleWebTechnologyVersion" match="\d\d\d" />
  </identification>
  <capture>
  </capture>
  <capabilities>
    <capability name="ecmascriptversion"       value="1.4" />
    <capability name="w3cdomversion"           value="1.0" />
    <capability name="supportsCallback"        value="true" />
  </capabilities>
</browser>

Everything newer than "Safari 85" was meant to be catched by the last definition. But due to a messed-up regular expression, "Safari 600" is falsly detected as "Safari60":

<capability name="appleWebTechnologyVersion" match="60" />

Should have been

<capability name="appleWebTechnologyVersion" match="60$" />

I resolved this issue by adding a custom file "App_Browsers\safari.browser" to my application with the following content:

<browsers>
  <browser id="Safari60_bugfix" parentID="Safari60">
    <identification>
      <capability name="appleWebTechnologyVersion" match="^\d{3,}$" />  <!-- At least 3 digits -->
    </identification>

    <capabilities>
      <!-- Same as in "Safari1Plus" -->
      <capability name="ecmascriptversion" value="1.4" />
      <capability name="w3cdomversion" value="1.0" />
      <capability name="supportsCallback" value="true" />
     </capabilities>
  </browser>

  <browser id="Safari85_bugfix" parentID="Safari85">
    <identification>
      <capability name="appleWebTechnologyVersion" match="^\d{3,}$" />  <!-- At least 3 digits -->
    </identification>

    <capabilities>
      <!-- Same as in "Safari1Plus" -->
      <capability name="ecmascriptversion" value="1.4" />
      <capability name="w3cdomversion" value="1.0" />
      <capability name="supportsCallback" value="true" />
    </capabilities>
  </browser>
</browsers>

Otway answered 22/9, 2014 at 16:50 Comment(15)

It's also worth noting the bug reported in forums.asp.net/t/955969.aspx?Mastering+Browser+Definition+Files, which can stop your additional browser files being picked up. – Parted 25/9, 2014 at 9:57

To save people reading the above link, you need to "touch" (ie. edit and save) any other file in the /App_Browsers folder in order to trigger your new .browser file being picked up. – Paleolith 3/10, 2014 at 0:16

I have a client having an issue with this. I want to test and fix on my own machine but for some reason I don't have the problem. I've checked mozilla.browser and that's incorrect and I don't have anything in App_Browsers or web.config to fix the issue. What else could be overriding the mozilla.browser file? – Threephase 8/10, 2014 at 8:25

A further clue is that if I add the fix to the App_Browsers folder (even though the fix is required) I get the following error message: "The browser or gateway element with ID 'Safari60' cannot be found." – Threephase 8/10, 2014 at 9:56

@contam I think you meant aspnet_regbrowsers.exe -i aspnet_regsql configures SQL server or at least it did for me on server 2003. – Thermogenesis 6/11, 2014 at 17:4

@Thermogenesis : I did a typo, here is the correct comment, thank you! I also suggest, if you decide to change the original mozilla.browser file, to execute the command: \WINDOWS\Microsoft.NET\Framework\\aspnet_regbrowsers.exe -i it recompiles the rules. The rules explained in this solution apply to framework version 2.0. Here is the link msdn.microsoft.com/en-US/library/ms229858(v=vs.80).aspx – Munn 7/11, 2014 at 9:43

I read at MSDN that Microsoft suggests NOT to change the original files as they might be overwritten by future Windows Updates. Another thing: The App_Browsers solution will not work with Mono (and is not required there anyway) since it doesn't have a "Safari60" definition. Use a recent /etc/mono/browscap.ini from browscap.org instead. – Otway 8/11, 2014 at 6:47

Thanks for posting this article, you saved our project today! – Antimacassar 12/11, 2014 at 16:34

Also same issue & fix for Version 8 of Safari – Retardant 12/11, 2014 at 18:14

@Jules: I am getting an "The browser or gateway element with ID 'Safari60' cannot be found" error when I implement the solution mentioned above. Any ideas on what I could be doing wrong? – Smuggle 2/3, 2015 at 19:28

@Otway can you please update this for ios 8.4 . this generic file is not working in ios version 8.4 – Grim 20/7, 2015 at 5:51

Seems to work for me with iOS 8.4. UA is "Mozilla/5.0 (iPod touch; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12H143" – Otway 21/7, 2015 at 15:32

@Otway I have a problem. It may be the same problem with yours. I explained the sutiation in another discussion. I hope you will offer me a solution. Thankss – Westerman 27/8, 2015 at 9:11

@Otway #32243353 – Westerman 27/8, 2015 at 10:39

@AjitGoel, @Jules: It might just be the case you're not running your application on .NET 2.0 anymore. In the 4.0 version, there are new browser definition files, check out C:\Windows\Microsoft.NET\Framework[64]\v4.0.30319\Config\Browsers which don't contain the broken rules mentioned in this answer. So there's no need to fix them, either, and that's also the reason why ASP.NET complains about the non-existend id Safari60. – Sacramentarian 4/9, 2015 at 12:50

The issue reproduces only when one uses the custom browser capability feature, i.e. one has .browser files in his/her \App_Browsers folder. The reason is that: Microsoft once released a fix (see http://support.microsoft.com/kb/2836946 for more details) which addressed some browser capability issues including the issue we are seeing here; however, the fix would not be in effect when one uses the custom browser capability feature due to compatibility issues. Therefore, for anyone who uses custom browser capability files, unfortunately, the best way to resolve the reported issue is to adopt the workaround provided by Tobias81.

Broddy answered 6/1, 2015 at 22:57 Comment(0)

I implemented the solution mentioned above by @Tobias81 and I got a "The browser or gateway element with ID 'Safari60' cannot be found" error. I therefore fixed the issue by changing the element in my application's web.config to match the newer version and assign the correct capabilities.

<configuration>   
  <system.web>     
    <browserCaps>       
      <filter>
        <case match="AppleWebKit/600">EcmaScriptVersion = 1.5           
          supportsCallback = true         
        </case>       
      </filter>     
    </browserCaps>   
  </system.web>
</configuration>

Smuggle answered 2/3, 2015 at 20:28 Comment(3)

In my application asp.net validations were not working for Apple IOS8 and MAC safari. Really above help was useful for me. It supports now on Apple IOS8 and MAC safari also. – Okechuku 29/7, 2015 at 12:36

This was working fine with old version of IOS like 8 but not working with latest IOS 9.1. Please help.... – Okechuku 21/11, 2015 at 15:9

Issue has been resolved by replacing match value to "AppleWebKit/601". Its working fine with latest IOS 9.1. – Okechuku 21/11, 2015 at 15:20

Recommended topics

Hot tags