Error calling CreateNewDocumentWithRedirect in IE11 and Chrome

For one of our customers we had to create a custom ‘New Document’ functionality. Since this customer had a lot of different document templates, but all templates have the same fields, the normal way to do this is to create a new content type for each document template. This is due to the fact that there is a one-to-one relationship between a content type and the document template assigned to it. One content type can’t have more than one document template.

Luckily there are some good examples out there on creating a custom new document dialog:

http://spandothers.wordpress.com/2013/04/24/sharepoint-replacing-the-new-document-button-with-something-functional/
http://www.macaw.nl/weblog/2012/8/extreme-new-document-button-makeover

All of these solutions create a popup window in which the proper template is selected. We opted for a different option, because pop-ups are generally UX unfriendly. We created a panel that would become visible when clicking the new button. That panel would be created based on a tree structure defined in the termstore. You store the document templates in a shared location, and also define that location in the termstore when creating the tree, by using local properties on the terms.

In the end it all comes down to one of two javascript calls to actually create the new document based on the appropriate template: createNewDocumentWithRedirect and createNewDocumentWithProgId. Both these solutions work, and while it can be tricky to get the attributes in the proper format, once that is done you should be solid… Until your client uses IE11. When using IE11, rather than creating a new document, the user is confronted with a SharePoint unexpected error “The template must exist in the Forms directory of this document library.”. The same javascript code works fine in IE10 though, or when you render the page in any other mode then IE11. So the template can’t be in an invalid location right? Right.

The difference between IE11 (or Chrome for that matter) and all other modes comes down to how the javascript is handled. Below you’ll find the actual javascript (from core.js) that is being called.

It turns out that the function ‘IsClientAppInstalled’ (called in createNewDocumentWithRedirect, displayed from line 56) returns false for IE11 and true for any other version of IE. This means that the next function called is createNewInBrowser rather than createNewInClient, even though we are positive the client has Office installed. That function is meant for InfoPath based forms, and not for documents, which causes it to crash.

To overcome this issue the solution is easy. We simply called createNewInClient directly, because we are certain all users do indeed have Office installed. Gotcha!

P.S., if there is anyone out there that is interested in the Termstore based New Document solution, let me know and I’ll draft up a different post containing the entire solution.