Recently I’ve encountered multiple issues at different client sites that all led back to SharePoint / Internet Explorer compatibility problems. On two entirely separate farms, SharePoint 2010 was generating a correlation error when someone attempted to select a user from the People Picker:
System.InvalidOperationException: Namespace prefix ‘xsd’ is not defined. At System.Xml.Serialization.XmlSerializationReader.ToXmlQualifiedName(String value, Boolean decodeName) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderDictionaryEntryArray.Read1_Object(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderDictionaryEntryArray.Read2_DictionaryEntry(Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderDictioaryEntryArray.Read3_ArrayOfDictionaryEntry()
Additionally, a number of weird, unexplainable problems were occurring. These ended up disappearing when users changed the browser mode from IE9/IE10 to IE8 in F12 developer tools. Obviously, then, the source of the problem lay in some sort of compatibility issue between SharePoint and Internet Explorer 9 and/or Internet Explorer 10.
To fix browser incompatibility problems, I found a number of people on forums and blog posts recommending the use of the “X-UA-Compatible” declaration inside a meta tag placed inside the head. For example:
<meta http-equiv=”x-ua-compatible” content=”IE=8″ >
Since the problem is SharePoint, and I know that SharePoint always uses a master page – either the one out-of-the-box, v4.master, or a custom master – than all I need to do is add the compatibility tag, right?
Well actually the out-of-the-box master already has this tag, and in every custom master page I examined, the page author had copied this tag. What was happening?
Actually there were two things going on:
- The People Picker does not use v4.master or whatever other master you set as the Site Master Page or the System Master Page. The actual master is calledpickerdialog.master, and it lives in the 14 folder, inside the Templates > Layouts subfolder.
If you examine this master, all you will see is a plain old “head” tag followed by the meta tag generator, Microsoft SharePoint. There is no compatibility tag.
<head>
<meta name=”GENERATOR” content=”Microsoft SharePoint” />….
- Both site collections with the problem were in the Intranet. According to Microsoft, Intranet sites display in compatibility mode by default. If you check Internet Explorer’s Tools menu > Compatibility view settings, you’ll see a checkbox that says, “Display all intranet sites in Compatibility View.” If your website is in the Intranet (as many SharePoint sites are), the compatibility view that Internet Explorer is setting will override your rendering directives in the master page and elsewhere, unless you add an emulate tag.
This last statement (#2) begs the question, “So what version does Internet Explorer use when Compatibility View is turned on?”
As per Microsoft:
“In Compatibility View, websites will be displayed as if you were viewing them in a previous version of Internet Explorer…”
From: http://windows.microsoft.com/en-us/internet-explorer/products/ie-9/features/compatibility-view
In reality, as noted in this post, compatibility view in Internet Explorer “is different under some circumstances to the actual old version, one does not precisely emulate the other, and I’ve seen some bugs which appear to belong to compatibility mode alone.” (From: http://webmasters.stackexchange.com/questions/29747/what-version-of-ie-does-compatibility-view-use-by-default.)
Since compatibility view in Internet Explorer is more or less hit-and-miss, it is better for the Web Developer/Administrator to control page rendering themselves.
The following was written a while back, but the principal is still true:
In the event that a user selects Compatibility View for your site, you can “bring them back” to your desired layout mode via use of the version targeting <META> tag / HTTP header. A new content value, ‘IE=EmulateIE8’, rounds out the list of supported values and assists in this particular scenario.
|
Content Value |
Details |
|
IE=EmulateIE8 |
Display Standards DOCTYPEs in IE8 Standards mode; Display Quirks DOCTYPEs in Quirks mode. Use this tag to override compatibility view on client machines and force Standards to IE8 Standards. |
From: http://blogs.msdn.com/b/ie/archive/2008/08/27/introducing-compatibility-view.aspx
All that being said, if your site is not on the Intranet and nothing use is triggering compatibility view, then just add the x-ua-compatible tag so that it renders underneath the page head. You can add it to the master page, or you can add it as a custom HTTP header.
However if your site is in the Intranet, you can push down group policy that unselects “Display all intranet sites in Compatibility View,” or if that’s not possible, you can force the browser to emulate an earlier browser with the “IE=Emulate” meta tag. The downside to this, of course, is that any JavaScript, HTML, CSS, etc. that need a later version of IE to work will suffer. In that case, the decision to where to use compatibility / emulate tags will take some planning and thought.
Internet Explorer 10 and SharePoint
If SharePoint is having problems with IE 10, then the previous recommendation for compatibility and/or emulate tags still holds true. However you may notice additional problems with IE10 that are actually a problem with the .NET Framework and not SharePoint itself.
As part of the explanation for an ASP.NET hotfix, Microsoft states:
“By default, ASP.NET uses sniffing technology for the user agent string to detect browsers. The browser definition files cover a certain range of browser versions. However, as the version numbers increase, ASP.NET might not recognize new versions of a browser by using the user agent string. In this case, ASP.NET might handle these versions as an unknown browser. For example, ASP.NET cannot recognize Windows Internet Explorer 10 that has the following user agent string:
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)”
From: http://support.microsoft.com/kb/2600100
The Microsoft hotfix modifies the ie.browser definition file so that ASP.NET recognizes IE10. For more details on this problem, see these blog posts:
Conclusion
The big take-away from all this – at least for me – is to check browser compatibility when strange problems start happening first, before spending hours on end pouring through logs and Internet forum posts. The easiest way to do this is simply press F12 when a problem occurs and change the browser mode. If changing the browser in F12 fixes the problem, then you know that somewhere there’s some browser incompatibility with SharePoint.
References:
SharePoint 2010 and IE10 compatibility problems – Resolved,http://gigajim.com/blog/2012/12/11/sharepoint-2010-and-ie10-incompatibility
Bug and Fix: ASP.NET fails to detect IE10…,http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.asp
Hotfix for problem with SharePoint PeopleEditor in IE-9,http://sharepoint.stackexchange.com/questions/27251/hotfix-for-problem-with-sharepoint-peopleeditor-in-ie-9
Intranet sites ignoring X-UA-Compatible HTTP header,http://stackoverflow.com/questions/14394179/intranet-sites-ignoring-x-ua-compatible-http-header
How fix Document mode restart in IE 9,http://stackoverflow.com/questions/11095319/how-fix-document-mode-restart-in-ie-9/11096186
Master page for html5 and css3, http://chuvash.eu/2011/10/12/master-page-for-html5-and-css3/
SharePoint 2010 and IE9 compatibility, http://social.msdn.microsoft.com/forums/en-US/sharepointgeneralprevious/thread/90b3835c-6754-4bb6-9fd4-b74f16f236ff
Namespace prefix ‘xsd’ is not defined,http://davemcmahon81.wordpress.com/2012/04/22/namespace-prefix-xsd-is-not-defined/
