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:
- SharePoint navigation menus not functioning correctly
- SharePoint ribbon menu options being disabled for all users
- SharePoint People picker appears to hang when searching for a user
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:
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:
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.
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:
- 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)
- Add the following text to the file:
- Save and close the file
- 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!!!