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

Question

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).

Wish I'd been able to find this post yesterday - I just came on to write up exactly the same thing. — Yellowfog, Sep 25 '14 at 09:54

score 57 · Accepted Answer · edited Sep 04 '15 at 12:46

57

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>

edited Sep 04 '15 at 12:46

Oliver

8,258
7
64
94

answered Sep 22 '14 at 16:50

Tobias81

1,730
1
13
16

1

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

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. – user2444499 Oct 03 '14 at 00: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? – Jules Oct 08 '14 at 08: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." – Jules Oct 08 '14 at 09: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. – stoj Nov 06 '14 at 17:04
2

@stoj : 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 http://msdn.microsoft.com/en-US/library/ms229858(v=vs.80).aspx – Matteo Conta Nov 07 '14 at 09: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 http://browscap.org/ instead. – Tobias81 Nov 08 '14 at 06:47
Thanks for posting this article, you saved our project today! – Nick Lewis Nov 12 '14 at 16:34
Also same issue & fix for Version 8 of Safari – Don Thomas Boyle Nov 12 '14 at 18:14
Thank you Tobias, this saved us :D – Alexus Nov 25 '14 at 18:36
@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? – Ajit Goel Mar 02 '15 at 19:28
@Tobias81 can you please update this for ios 8.4 . this generic file is not working in ios version 8.4 – User_3535 Jul 20 '15 at 05: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" – Tobias81 Jul 21 '15 at 15:32
@Tobias81 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 – Habib Adıbelli Aug 27 '15 at 09:11
@Tobias81 http://stackoverflow.com/questions/32242853/sharepoint-2013-site-ntlm-authentication-javascript-dopostback-doesnt-work-in-sa – Habib Adıbelli Aug 27 '15 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`. – Oliver Sep 04 '15 at 12:50

score 3 · Answer 2 · answered Jan 06 '15 at 22:57

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.

score 2 · Answer 3 · answered Mar 02 '15 at 20:28

2

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>

answered Mar 02 '15 at 20:28

Ajit Goel

3,264
3
42
77

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. – Shoeb Jul 29 '15 at 12:36
This was working fine with old version of IOS like 8 but not working with latest IOS 9.1. Please help.... – Shoeb Nov 21 '15 at 15:09
Issue has been resolved by replacing match value to "AppleWebKit/601". Its working fine with latest IOS 9.1. – Shoeb Nov 21 '15 at 15:20

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

3 Answers3

Linked