Rare bug in SharePoint with IE9 when account names have commas

Configured a certain way, Active Directory will generate account names like so: ”Lastname, Firstname”. Although SharePoint strongly recommends you not to use account names with special characters, it seems to mostly be able to handle this.

Now, user links generated with SharePoint’s renderUserField look something like this:

Which works perfectly fine. However, with commas in the account name, the account name part of the link will instead look like this: ”turing%2C%20alan”. URL encoded comma is %2C and space is %20. So far, so good. Try it in Firefox, Chrome, IE10+, no problems. Try it in IE8, works great. But not IE9. Clicking the link in IE9 sends you to a url containing ”turing%252C%20alan”. Spot the error? %252C looks a lot like double encoding. And it is. But why is this only a problem in IE9? I worked my way through many suspects, including encodeURI and escapeProperly/unescapeProperly (yes, these do exist in SharePoint). Nothing came up. And the odd thing is that the URL in the link I click doesn’t match the URL I end up at. This because of the onClick handler, of course!

After a lot more work, I find out why this bug is only active in IE9. There’s a piece of code, triggered by the click handler, that decodes the URL encoded link, does some stuff with it, and encodes it again. This code is blocked by two conditions. It is only reached if the MDS is on and the browser is Internet Explorer 9 or less. MDS doesn’t work in IE8. That only leaves IE9.

But why the double encoding? The thing is, encodeURI will not touch commas, they don’t need encoding. Try it out in your console:

And of course, if you encode something and then decode it the same way, you should get the original string back, right? What if you use encodeURIComponent to encode, and encodeURI to decode? Bad things happen. Because encodeURIComponent _does_ encode commas. So lets say you know a certain string is encoded already, and you want to decode it, do some stuff with it and encode it again. You might write this:

Try that code with this URL: ”http://example.com/turing%2C%20alan/”. You should get ”http://example.com/turing%252C%20alan/”. Mystery solved!

But that just raises another question, really. Why was the comma urlencoded in the first place? The culprit can be found in SharePoint’s ”init.js”.

Back to the onClick handler. It calls a function called GoToLinkOrDialogNewWindow, which uses the href of the a tag you clicked and, amongst other things, creates a URI object from it. URI is a type of object defined in ”init.js”, and has lots of nifty functionality. It automatically encodes its content too, and when you call getString on the object, you get a nicely formatted URL string. Except, of course, when there’s a comma in it. You see, URI doesn’t use encodeURI. Instead, it breaks the link up into parts, a bit like this: http-:-//-example.com-/turing, alan/ (using – as a delimiter). It then fastidiously encodes each component, of course, using encodeURIComponent.

So who’s wrong? No one, really. The problem is that one part of SharePoint assumes a URL to be encoded using encodeURI. Another part of SharePoint encodes the URL by looping over parts of it and calling encodeURIComponent. Communication breakdown.

En reaktion på “Rare bug in SharePoint with IE9 when account names have commas


E-postadressen publiceras inte. Obligatoriska fält är märkta *