One of the most exciting features in the upcoming Q4 2012 Service Update is cross-browser support.  This will allow users to access CRM not only from Internet Explorer, but also from Chrome, Firefox, and Safari.  While this is great news, it is possible that custom JavaScript will stop working or cause an error when you upgrade.  It's worth pointing out that if you do not plan on switching from Internet Explorer to one of the other browsers, you do not need to update any of your code.  This process is only necessary if you plan on accessing CRM from the newly supported browsers.

The first step to making sure your code will still run after upgrading is to download the Custom Code Validation Tool.  This page contains a link to the validation tool at the bottom of the page, as well as detailed instructions on importing the tool into your CRM 2011 organization.

If you follow the instructions mentioned above, you will find yourself looking at a screen similar to this:


At the top left of the window is a list of all of the JavaScript and HTML Web Resources that exist in the current CRM organization.  When a file is highlighted, its contents are shown in the top pane, and a list of potential errors are shown in the bottom pane.  You can go down the list of all of your Web Resources and see if any of them have potential errors.

Everything up to this point has been pretty straightforward, and has not required any knowledge of JavaScript.  However, if you are going to be reviewing your JavaScript for potential errors, you will want to have a working knowledge of JavaScript.  The reason for this is because this tool won't tell you definitively what needs to be fixed and what doesn't.  Instead, it will flag potential errors that may not run correctly in the other browser.  In other words, just because the tool flags something doesn't necessarily mean it needs to be updated.  Let’s look at an example of code that does need to be updated, and then a false positive that doesn’t need to be modified.

Example 1


In this example, we have a function named disableLastName, that has two potential issues.  The first issue is the usage of crmForm.all.  A quick search for "javascript all collection" took me to this page, which says that the all collection is not supported by Firefox.  Even if you don't plan on using Firefox, it is still worth fixing because unlike Internet Explorer, the all collection does not exist on every HTML element in Chrome and Safari. 

The second potential issue is the use of the Disabled property.  This property is defined in an .htc file, which is an HTML Component file.  These files only work in Internet Explorer, which means they will be going away in the Q4 2012 Service Update.  Since .htc files won't be around anymore, the Disabled property will need to be replaced as well.

So how do we update this code?  If we take a look at the "Form Scripting Quick Reference" section in the Dynamice CRM SDK, there are two methods named Xrm.Page.getControl and setDisabled.  We can use these two methods to update the code to:


Because we are now going through the supported 2011 Xrm methods, this code is guaranteed to work in all supported browsers.

Example 2


In this example, we have a function named alertUserOnClick.  Imagine we have a custom HTML page, and we have a JavaScript function that will allow us to show the user an alert message any time a button is clicked.  As you can see, the tool has flagged the attachEvent method as a potential issue.  The reason this method was flagged is because attachEvent is only available in Internet Explorer.  However, if we look at the code, we can see we first check for the existence of the addEventListener method, which is the W3C standard method used to add an event listener to an HTML element.  If that method does exist, it will be used.  Only if the method doesn't exist do we fall back to the attachEvent method.  This is an example of the tool flagging a false positive.  Even though our code contains the attachEvent method, that section of code will only be executed when we are running Internet Explorer.

Unfortunately, it is impossible to go through every possible scenario of code that may or may not break.  Hopefully you now have a better idea of how to analyze your JavaScript for potentially breaking changes.  As I mentioned earlier, this is a task for someone who is familiar and comfortable with JavaScript, as this is a technical exercise and will require a working knowledge of the differences between the four browsers that CRM will support.