Notifications

1898 views

Troubleshooting Javascript errors in forms | Help, my form is broken!

 

Overview
Some of the most common issues seen by ServiceNow Customer Support are forms breaking in ways that can be frustrating to track down and large in user impact. These issues often generate P1 incidents because users are not able to perform work.

Some symptoms of a form broken due to Javascript errors are:

  • Unable to click on any reference icons, like clickthrough or the magnifying glass
  • Unable to get the ServiceNow right-click context menu on the form or form objects
  • Unable to use some/all UI Actions, like Save or Update
  • Unable to save data in certain fields
  • Form does not load completely

Some potential causes of broken forms are:

  • Client Script/UI Policy/UI Script throwing errors
  • Malformed formatters
  • Gremlins

The above lists are not exhaustive, but they do give a sampling of the issues you may face. This article explains the somewhat algorithmic methods and troubleshooting theory you can use to determine what the issue is and where it is being caused.

Prerequisites


If you are not familiar with the development tools in your preferred browser, now would be a good time to take a break from this article and see what you can find on how to use them. The screenshots and specific instructions in this article use Chrome, but most browsers have similar functions available.

A few resources:

Ready, fight!
There are several places where things can go wrong and completely break a form. Following is a full list of common issue causes, but, as always with a platform the size of Service Now, this list is not exhaustive and there can always be one-off items that will drive you crazy. That said, if you get a good handle on the locations below and the troubleshooting steps, you should be in a good position to handle most of the form issues that can occur. The issues are listed in a not scientifically aggregated order of the most to the least common causes:
  • Client-side scripting conflict/error
    • UI Policy
    • Client Script
    • UI Script
    • UI Action
    • Display Business Rules
  • Server/Client-side scripting conflict/error
    • UI Macros/UI Pages
      • UI Formatters
      • Reference Decorations
  • Duplicate fields on the form
  • Missing fields on the form
  • Embedded Lists
  • Related Lists
    • Bad data
    • Missing relationships 

Debugging errors with nice error messages

Your first step should always be to check for client-side errors in the Javascript console of the browser. If you are lucky, the issue you are seeing will throw an error that includes a specific code location. You can then easily track down to a specific script, for example, a Client script. The console error might look similar to the following:

 

As you can see, there is an error. At this point, right-click, typeahead, and the magnifying glass no longer work for reference fields, and various other issues may be present when displaying this form. Because there is a console error, we may be able to laser focus into what is causing the problem. From the part of the error displayed in red, if you take a look at the stack, you can see that we are evaluating a UI Policy:

Uncaught ReferenceError: ... at ui_policy_onLoad

If you look about 5 lines higher, you can see that we have something that looks like a sys_id:

316b1990db54fa00ea325404ce961903

After you have that information, you can bring up the UI Policy in question (sys_id = 316...), determine where the code issues take place, and work out what the issues are. It is not always that easy to find a sys_id, but if you scan the error or click on the error and scan upwards in the code that is presented, you can generally find some indication as to what item is causing problems. I don't spend too much time on this. If I can easily spot a sys_id and find a matching record, I'll turn that record off and see if the issue goes away to confirm. Otherwise, it is time to step into the nuclear methods.

Dealing with other errors

As you have probably noticed, many issues do not give you a nice, specific error message. The number of times the first example happens is likely outweighed by the times the form is broken, but there is no cause or errors readily available. When that happens, it is time to break out the big hammer and disable everything until the issue goes away. Depending on the type of error, you may start in one place vs. another place, but, in general, there is no specific order in which to try the following items. Just keep going until the issue stops occurring. After you determine what type of object is breaking things, we can move on to finding the specific object that is causing the issue and dig in further.

The starting points:

  • Client Scripts
  • UI Policies
  • Global UI Scripts
  • Form Elements
    • Fields
    • Formatters
    • Embedded Lists
  • Related Lists

The quickest and easiest method for each of the above items is to turn them all off (active=false) and test. That works for Client Scripts, UI Policies, and Global UI Scripts, but is not as simple as setting them to active=false. For form elements and Related Lists, create a new view for the form in question.

Generally speaking, if you cannot use the right-click context menu to Configure > Form Layout, you can still hit the menu icon  in the header to find that option. After the Form Layout popup opens, create a new view and remove all fields except the display column (usually Number).

If you can no longer reproduce the issue, you know it is related to an element on the form. If the behavior still occurs, you need to use Configure > Related Lists for your new form view and remove all of those as well.

At this point you should know what general area is causing the issue and you can move on to the next section. If you do not know the general area, have already turned off all Client Scripts, UI Policies, Global UI Scripts, Form Elements, and Related Lists, and are still experiencing the issue, it is time to open an incident with ServiceNow Customer Support.

Finding the culprit:

If you are reading this section, you need to determine which of the now disabled elements is specifically causing the issue. To do this, I most often use the 50/50 method. You already turned all of the items off, or removed all of the items from the form, so now, set half of them back to active or put half of them back on the form. Following is an example.

I have 8 client scripts, and I know that when they are off, the issue does not occur. So, I pick 4 and turn them back on. With those 4 on, the issue still does not occur, so I pick 2 of the remaining 4 and turn those back on. I notice that the issue starts occurring again.  So, of the 2 I just turned back on, i turn one of them off and the issue no longer occurs. Now I know it is the one I just turned off that is causing the problem. If it had been the other way - where I turned it off and the issue still occurred - I would know it was the one I had not touched.

For those more visual learners, see the tables below (note that blue indicates "changed in this step").

Starting position after disabling everything:

Client Scripttrue or false
CS1false
CS2false
CS3false 
CS4 false 
CS5 false 
CS6 false 
CS7 false 
CS8 false 

Result: No issue

 

Client Scripttrue or false
CS1true
CS2true
CS3true 
CS4 true 
CS5 false 
CS6 false 
CS7 false 
CS8 false 

Result: No issue

 

Client Scripttrue or false
CS1true
CS2true
CS3true 
CS4 true 
CS5 true 
CS6 true 
CS7 false 
CS8 false 

Result: Issue

 

Client Scripttrue or false
CS1true
CS2true
CS3true 
CS4 true 
CS5 false 
CS6 true 
CS7 false 
CS8 false 

Result: Issue

 

In this case, I know that CS6 is my culprit. Had the last flip gone the other way, it would have looked as follows:

Client Scripttrue or false
CS1true
CS2true
CS3true 
CS4 true 
CS5 true 
CS6 false 
CS7 false 
CS8 false 

I still would have known that CS6 was the culprit, since the issue occurred when 5 and 6 were on, but did not occur when 5 was on. 

Now I can go into the client script and determine the cause. Are there syntax errors?  Referencing fields that do not exist on the form?  The issues can be many and varied, but knowing which script is causing trouble is easily 85% of the battle.

For form elements, the process is the same, except that instead of activating and deactivating the objects, you just add/remove them from the form. After you have narrowed down what is causing the issue, you can look at what makes that field/list/etc different from the others, and proceed from there.

  

So, I know what is causing the issue now, but I cannot figure out why

You have given it your all. You determined which element is causing the issue and know that when that particular element is not in play, the issue does not occur. But, you have looked it over carefully and still cannot figure it out. What now?

Try clearing the instance cache by navigating to https://instance.service-now.com/cache.do.

If that does not help, try clearing your browser cache.

Still nothing?

That is where ServiceNow Customer Support comes in. Open an incident and explain:

"When I have <this element> <enabled/on the form> bad things happen. I have investigated the item in question, but cannot determine the problem. Please help!"

Instead of:

"I can't right click in my form."  

Remember to include all of the necessary steps to reproduce, including any key user information or anything required to reproduce the issue. Equipped with the targeted information, Customer Support can dive in and hopefully provide a much faster turnaround for your request.

Article Information

Last Updated:2017-04-17 11:13:30
Published:2017-01-23