SharePoint 2010 | Caveats when upgrading master page to IE9 (with solutions)

Problem:
One of the biggest issues with branding is our "friend", Internet Explorer.
When we talk about SharePoint, specially SharePoint 2010, we are typically bound to one version of Internet Explorer, where everything works great, but as soon as we move to another version, all hell breaks loose.

In practice, this happens when we change this line,

< meta http-equiv="X-UA-Compatible" content="IE=8" />

to something like

< meta http-equiv="X-UA-Compatible" content="IE=9" />


Why would you do this?
Well, among other things, you get access to CSS3. Otherwise, even if you have IE9+ installed, you will not get CSS3 because the browser will be rendering in IE8 mode. Many other limitations of IE8 will apply as well.

Should you do this?
Ideally, no. This raises issues as soon as this is enabled and I'm sure not all issues have been found.
However, in a small and/or public facing application, where only a few areas, easily testable, are available, this can be achieved using the code fixes provided below.

What happens?

  • Rich text editors break (form.js)
    • IE8 handles "document.frame" differently (replace curly brackets with square)
  • People pickers break (entityeditor.js)
    • 'data' is not properly serialized
Example:




Solution:

The solution, at least for these two javascript errors, is to override the ootb functions that are breaking.

So we will create a form.ie9fix.js and a entityeditor.ie9fix.js and reference them on our master page, in the < head > area.

form.ie9fix.js




entityeditor.ie9fix.js


Resouces;

form.ie9fix.js

entityeditor.ie9fix.js

Comments

Popular posts from this blog

Mobile development opportunities

Breaking down document locking in SharePoint

Working around X-Frame-Options for iframes