Safari 7.1 on MAC Computers causes multiple Issues with SharePoint

The Issue

Apple recently released a new version of Safari for MAC computers. The browser version is 7.1. The browser might be great, but SharePoint 2010 as well as MOSS 2007 all of a sudden have a number of User Interface issues including but not limited to:

  1. SharePoint navigation menus not functioning correctly
  2. SharePoint ribbon menu options being disabled for all users
  3. SharePoint People picker appears to hang when searching for a user

The Cause

I have to be honest, there is nothing wrong with the new browser. As you may already know, SharePoint 2010 and MOSS 2007 are just web applications that are based on ASP.NET 2.0. The root cause of this issue lies at the ASP.NET layer and can affect any ASP.NET 2.0 web application. The issue does not exist in ASP.NET 4.0 and as a result, SharePoint 2013 is not impacted by this problem.

ASP.NET reads the user agent of the incoming request, and using regular expressions, assigns a Browser ID to the incoming request. ASP.NET uses browser definition files to assign browser IDs. The browser IDs are then used to enable or disable “capabilities” such as AJAX, certain types of controls etc. Applications such as SharePoint also use the browser ID to change the way they render content to achieve the best user experience.  These browser definition files are located by default at Drive:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Browsers. The user agent for Safari 6.0 contained AppleWebKit/536.26 and ASP.NET was assigning the browser ID "Safari1Plus" to this and other recent Safari browsers based on the following entry in Mozilla.browser:

   1: <browser id="Safari1Plus" parentID="Safari">
   2:        <identification>
   3:            <capability name="appleWebTechnologyVersion" match="\d\d\d" />
   4:        </identification>
   5:        <capture>
   6:        </capture>
   7:        <capabilities>
   8:            <capability name="ecmascriptversion"       value="1.4" />
   9:            <capability name="w3cdomversion"           value="1.0" />
  10:            <capability name="supportsCallback"        value="true" />
  11:        </capabilities>
  12: </browser>

Notice how the regular expression “\d\d\d” on line 3 results in a match for 536.26 and as a result, a browser ID of “Safari1Plus” gets assigned to requests with this user agent. SharePoint 2010, rightly so, assumes that the latest version of Safari would have the ID “Safari1Plus”.

Several years ago, there used to be a Safari browser that had AppleWebKit/60 in the user agent string. ASP.NET uses the browser ID “Safari60” for these browsers and does not enable AJAX since the browser is so old. Here is the entry in Mozilla.browser that was added for these old Safari browsers:

   1: <browser id="Safari60" parentID="Safari">
   2:        <identification>
   3:            <capability name="appleWebTechnologyVersion" match="60" />
   4:        </identification>
   5:        <capture>
   6:        </capture>
   7:        <capabilities>
   8:            <capability name="ecmascriptversion"       value="1.0" />
   9:        </capabilities>
  10:  </browser>

The problem is that Safari 7.1 has AppleWebKit/600.1.17 in the user agent string and as a result, it ends up getting matched with the Safari60 definition. The regular expression here (line 3 in the snippet above) should have been ^60$ to avoid a match for 600. Because the BrowserId is incorrectly detected as Safari60, SharePoint does not enable the Menu controls for this browser Id. Also, due to a missing supportsCallback attribute in the browser definition file, AJAX calls do not function correctly which SharePoint uses when working with Ribbons and the people picker.

The Solution

Update : A permanent fix for this issue was released with the March 2015 Public Update for SharePoint 2010. If you install this or a later update, you will not need to apply the workaround mentioned below. I highly recommend upgrading your environment to the latest version instead of relying on the manual workaround. However, if you cannot immediately upgrade, you may use the workaround temporarily.

The ideal solution would be to update the Mozilla.browser file located at Drive:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Browsers with correct regular expressions (^60$ for Safari60 and ^85$ for Safari85) and then run aspnet_regbrowsers.exe –i to re-deploy the browser definitions to all applications. However, strictly speaking, Mozilla.browser file is a system file that may get updated by a future Microsoft update and overwrite your changes. Keeping that in mind, the best solution would be to create a new browser definition file in the local IIS virtual directory for the affected SharePoint web applications. Here are the steps that you can use to apply this solution:

  1. Inside the App_Browsers folder for your SharePoint web application (usually located at Drive:\inetpub\wwwroot\wss\VirtualDirectories\port\App_Browsers), create a new text file named safari.browser (Please ensure it is not safari.browser.txt, .browser must be the extension of the file)
  2. Add the following text to the file:
       1: <?xml version="1.0" encoding="utf-8" ?>
       2: <browsers>
       3:   <browser id="Safari6xxFix" parentID="Safari60">
       4:     <identification>
       5:       <capability name="appleWebTechnologyVersion" match="60\d" />
       6:     </identification>
       7:     <capture>
       8:     </capture>
       9:     <capabilities>
      10:        <capability name="ecmascriptversion"       value="1.4" />
      11:        <capability name="w3cdomversion"           value="1.0" />
      12:        <capability name="supportsCallback"        value="true" />
      13:     </capabilities>
      14:     <controlAdapters>
      15:       <adapter controlType="System.Web.UI.WebControls.Menu"
      16:                adapterType="" />
      17:     </controlAdapters>
      18:   </browser>
      19: </browsers>

  3. Save and close the file
  4. Verify that the issues are now resolved.

IMPORTANT: You must do a “dummy edit” on the compat.browser file located in the App_Browsers folder of your web application to force a recompilation of the browser definition files and for the solution to take effect. Simply open the compat.browser file and add a space at the very end of the file and save it back. You can remove the space and save it again if you wish, but an edit to compat.browser should force the recompilation.

Hope this helps. Happy SharePointing!!!

Comments (20)
  1. GregoryF says:

    Thanks for posting this excellent explanation of the problem our Mac 7.1+ users were experiencing with navigation on our SharePoint 2010.  I also appreciate that you included a solution at the bottom of your post that is more manageable than directly modifying the compat.browser file. For others implementing this solution you will need to remove the leading space on line 3 since .. id=" Safar.. doesn't work and"Safar.. does. Even though this solution works, we are looking forward to a hotfix so we don't have to manage the problem this way moving forward.  –  Greg

  2. Thanks for pointing out that extra space GrgoryF. I have updated the code.

  3. mat says:

    Hello Tehnoon, shouldn't it be safari.browser?

  4. Hi Mat. Are you referring to the dummy edit step? If so, then no, you have to edit compat.browser for the recompilation to occur since that is already "attached" to your application. safari.browser won't be picked by your application unless a recompilation occurs.

  5. Paul says:

    Big thanks for this, solved the problem some of our users were experiencing.

  6. Luis says:

    Are there any issues with IE 11 that we should also be on the lookout for with sharepoint 2010?  

    thank you.

  7. J Stewart says:

    If you enable the Develop menu you can change the user agent info that Safari shares to IE 7-10, Mozilla for Mac, even to Safari for IOS.  It may be very useful to do in these cases, since when you upgrade to 7.1 it resets whatever you have this set to, to "default"

  8. SPHall says:

    Hi Tehnoon

    Have you any news on a hotfix including these browser compat updates?



  9. Gmj says:

    Regarding the location of the appropriate App_Browsers folder:

    My application is on port 443 (HTTPS) rather than port 80 (HTTP), but there is no existing inetpubwwwrootwssVirtualDirectories443App_Browsers folder on the server.  

    Should the safari.browser file be added to the existing inetpubwwwrootwssVirtualDirectories80App_Browsers folder?

    I.e., do applications using both the standard HTTP and HTTPS ports look to the port 80 folder?

  10. Hi Gmj,

    Your web app should have a App_Browsers folder, and it could be different from the default path. The best way to identify the physical folder for your web application would be to open IIS Manager, right click on your Web Site and select "Explore". This will open up the physical folder for your site where you should see an "App_Browsers" folder. Please create the file safari.browser file in that folder.

  11. Gmj says:

    Thank you Tehnoon, that does it (and also addresses similar issues with Safari 8.0)!

  12. Shravani says:

    We have 4 app servers for load balancing. Do I need to create browser file on each of the server?


  13. Shravani: Yes, you have to do this on all servers in the load balancer. A permanent fix for this issue is being released with the March 2015 Public Update for SharePoint 2010

  14. Shravani says:

    Thats great news. Thanks so much Tehnoon!

  15. naijacoder says:

    Thanks for the solution but it doesn't work for me 🙁

    I have created the safari.browser and added it to the folder as you mentioned with the changes you made and edited the compat.browser as suggested but no luck.

    Any ideas what I nee to check

    Thanks in Advance

  16. James says:

    I have found it works on SharePoint with SP2 but not SharePoint with SP1.

  17. Marco Blauw says:

    Apple need to do some testing with safari next time before releasing this sort of update that breaks functionality in a key business application such as SharePoint. Safari and firefox are not really suitable for enterprise use.

  18. Venkat says:

    Thanks Tehnoon for the Fantastic solution.

  19. Andreas says:

    @Marco Blauw: LOL, that is the most misguided criticism I have ever seen.

  20. Diamant says:

    Great post. Solved my problems with ios safari and WSS 3.0/2007. Outstanding explanation of the problem.

Comments are closed.

Skip to main content