SharePoint Dragons

In a SharePoint 2013 environment we encountered the error “WPSC is undefined”. The WPSC (Web Part Page Services Component) is a JavaScript library that web parts use to communicate with each other client-side. We don’t feel the WPSC used that often nowadays (if that ever was the case), so maybe that explains why we couldn’t find that much info about this problem. The most interesting post was this one: http://sadomovalex.blogspot.nl/2010/02/fix-wpsc-is-undefined-javascript-error.html

But it talks about an issue in combination with FBA, and our problem existed on a page leveraging WPSC for client-side communication when using MSIE 10 or higher (whereas MSIE 9 worked fine). Also, in normal mode the error existed in MSIE 10 and up, in page edit mode it went away. There’s another post worth mentioning, and its this one: http://msharaky.blogspot.nl/2009/06/wpsc-undefined-javascript-error.html

Here, the author defines a dummy object and reports the error goes away. This is true of course, but also kills client-side communication. But, if you’re just looking for a way to suppress an ugly error message, this one does the trick.

To understand more about the problem, it’s worth mentioning that the WPSC object is defined in a JavaScript library called ie55up.js which is included by default. So, if you’ve changed your master pages and its not referenced anymore, then there’s the place where it needs to be corrected.

Another useful thing to know is that if you’re using the SharePoint ScriptLink control to include a JavaScript library into your page, the OnDemand attribute determines if such a library will be included on demand as needed, or immediately. The following line ensures a JS library is loaded on demand:

<SharePoint:ScriptLink ID=”scriptLink1″ runat=”server” Name=”MyScriptLib.js” LoadAfterUI=”true” OnDemand=”true” />

If the js library needs to be loaded immediately, the control just generates a script tag. If the js library needs to be loaded on demand, it generates calls to the SharePoint RegisterSOD() JavaScript function. This is interesting because a SharePoint page in edit mode loads the ie55up.js immediately (and thereby the WPSC), using the following client-side code:

<script type=”text/javascript” src=”/_layouts/15/ie55up.debug.js?rev=pVBnO13dp7gFq%2FZalDmroA%3D%3D”></script>

Remember that the page in edit mode works correctly in conjunction with WPSC.

Note: the script tag refers to a debug version of ie55up.js instead of the minified version. That is because we have configured SharePoint to do this by setting the debug attribute in the web.config file to true.

On the other hand, a page in normal mode that uses the WPSC but fails in MSIE 10 and up renders the ie55up.js library to be loaded on demand, like so:

<script type=”text/javascript”>RegisterSod(“browserScript”, “\u002f_layouts\u002f15\u002fie55up.debug.js?rev=pVBnO13dp7gFq\u00252FZalDmroA\u00253D\u00253D”);RegisterSodDep(“browserScript”, “strings.js”);</script>

Apparently there is some on demand script problem because in which case the ie55up library is registered successfully, but never gets loaded in MSIE 10 and up. Btw, the root cause of this we have yet to discover.

Another thing to note is that the RegisterSod() function is defined in init.js and looks like this:

function RegisterSod(key, url) {
    ULSxSy: ;
    key = NormalizeSodKey(key);
    var sod = new Sod(url);
    _v_dictSod[key] = sod;
}

Later on, we’ll be able to leverage the facts that all keys are stored in the _v_dictSod dictionary and ie55up.js gets registered using the “browserScript” key to our advantage.

In order to experiment with this problem, we needed an easy way to add JavaScript code to a SharePoint page that uses the WPSC. We decided to place a Script Editor web part on a page (page edit mode > ribbon > Insert > Embed Code) that uses JavaScript that uses WPSC to register for a predefined event that happens when a user presses F1 to get help. All that’s needed to determine when and if the WPSC problem is an issue for you is this code:

<script>
WPSC.RegisterForEvent(“urn:schemas-microsoft-com:dhtml”, “onhelp”, myfunc); // respond to predefined event for pressing F1
</script>

Now our approach for dealing with the “WPSC is undefined” problem has 2 sides. If the WPSC object exists (in older browsers and page edit mode for msie 10 and up) we need to do the following:
1 – Establish that the WPSC exists.
2 – Do required communication via WPSC. In this case, we’ll use the WPSC to respond to an F1 key press.

In situations where the WPSC doesn’t exist, our approach is like this:
1 – Establish that the WPSC object does NOT exist.
2 – Find the URL that SharePoint intends to use to load ie55up.js.
3 – Use the SP.SOD library to load ie55up.js on demand.
4 – Establish that ie55up.js is indeed loaded.
5 – Do client-side communication via WPSC. In this case, we’ll use the WPSC to respond to an F1 key press.

This results in code that can be used as a work-around for situations where the WPSC is undefined, making sure its loaded on demand and then do the things you want to do with a fully functioning WPSC. You can paste the following code in a Script Editor web part on a SharePoint page to see it in action (after pressing F1):

<script>
function myfunc()
{
  alert(‘Responding to help!!!’);
}

function WpscLoaded()
{
  execWpscCalls();
}

function execWpscCalls()
{
  WPSC.RegisterForEvent(“urn:schemas-microsoft-com:dhtml”, “onhelp”, myfunc); // respond to predefined event for pressing F1
}

if (typeof(WPSC) == “undefined” )
{
  // default src of js lib defining WPSC
  var url = “\u002f_layouts\u002f15\u002fie55up.js”;

  // get url that sharepoint stores to refer to WPSC lib
  if (_v_dictSod != null && _v_dictSod[“browserScript”] != null)
  {
    url = _v_dictSod[“browserScript”].url;
  }
  SP.SOD.registerSod(‘ie55up.js’, url);
  SP.SOD.executeFunc(‘ie55up.js’, null, function(){});

  // when done, WPSC is available 
  ExecuteOrDelayUntilScriptLoaded(WpscLoaded, “ie55up.js”);
}
else
{
  execWpscCalls();
}
</script>