People Editor Issues with Sharepoint 2010 in compatibility mode IE9 RRS feed

  • Question

  • Hello all,

    You might be aware that there are certain issues with SharePoint 2010 and IE9 compatibility mode. One of them is with the People Editor control throwing "Namespace prefix 'xsd' is not defined." exception. The immediate fix for this problem is discussed here : Sharepoint 2010 and IE9 compatibility

    As a fix what has been suggested is to override the OOTB javascript function "ConvertEntityToSpan()"  of entityeditor.js

    function ConvertEntityToSpan(ctx, entity)
    	var serializer=new XMLSerializer();
    	if(data.indexOf('<ArrayOfDictionaryEntry>') >= 0)
    		data = data.replace('<ArrayOfDictionaryEntry>','<ArrayOfDictionaryEntry

    However, this fix does not work entirely correct in the following scenarios:

    (a) If the user field is multi-valued and I try to add more users in 2nd attempt the "Namespace prefix 'xsd' is not defined." is thrown again.

    (b) The functionality of resolving the user name on pressing the "Enter" key gets broken. The focus of the text area doesn't seem to be sharp as it should be. Its very difficult to delete user names from the text area. In short, the UI of the <textarea> of the people picker doesn't seem to work too smoothly.

    I checked the same scenario SharePoint 2013 and found that PeopleEditor there works absolutely fine in the IE9/IE10 mode. In other words, the problems mentioned above ('a' and 'b') don't seems to occur there anymore.

    I investigated the entityeditor.js of [15] hive and learned that there were some difference in the target js function "ConvertEntityToSpan()" of [14] hive and [15] hive. I've replaced my target js function with [15] hive's function and problem (a) disappeared. However, problem (b) still remains.


    My question is what else are the places where I can compare such things betweeen the [14] hive and [15] hive and try to fix the problem (b) mentioned above.

    Any help would be greatly appreciated.

    Devang Bhavsar

    Wednesday, May 8, 2013 7:27 AM

All replies

  • I'm not sure if this should work on your side.

    It's quite simple and stupid if you may say but it works.

    Basically all our changes that requires HTML5 and CSS3 (which are why we upgraded the doc mode from IE-8 to IE-9) are all on our parent site front page. All other Child Site Collections just uses the rounded corner effect.

    What we did is create a duplicate Master Page which has IE-8 set as default doc mode and set that Master Page to all sites which are encountering error.

    This might be a simple and quick work around without overloading any SharePoint functionalities until Microsoft comes up with a hotfix for this issue.

    Artificial intelligence can never beat natural stupidity.

    Tuesday, September 10, 2013 9:47 AM