Interesting Interaction Between inlineHelpText and JSINHTMLENCODE()

If you have ever worked on more complicated Javascript on the Salesforce platform, you may have utilized the JSINHTMLENCODE() function. According to the docs, the JSINHTMLENCODE() function:

Encodes text and merge field values for use in JavaScript inside HTML tags by replacing characters that are reserved in HTML with HTML entity equivalents and inserting escape characters before unsafe JavaScript characters. JSINHTMLENCODE(someValue) is a convenience function that is equivalent to JSENCODE(HTMLENCODE((someValue)). That is, JSINHTMLENCODE first encodes someValue with HTMLENCODE, and then encodes the result with JSENCODE.

This is a very important function for protecting your application from Cross-site Scripting (XSS) attacks. Cross-site Scripting attacks are done by using malicious scripts injected onto a page and having them execute. By utilizing a function like JSINTHMLENCODE, you escape the script functionality so that instead of having a piece of code run, it just outputs the script as text.

JSINHTMLENCODE() and inlineHelpText Oddity

JSINHTMLENCODE and inlineHelpText have a bit of an awkward interaction. The easiest way to show those would be through an example. Let’s take a look at a very simple page I built to illustrate this problem. First off, I created a new object called Widget__c.

On this object, there is a Dimensions__c field. The important part to note here is that the Dimensions__c field has help text specified, specifically “Dimensions for a widget contains the height by width (i.e. 10×6)”.

I’ve gone ahead and created a very simple Visualforce page that simply alerts the help text on the Dimension__c field when a link is clicked. The code looks like:

So, everything is working as we expect at this point, correct? We are pulling in help text, which could be manipulated with a malicious script, so we are protecting ourselves by utilizing JSINTHMLENCODE(). We correctly set the variable based on the help text on the Dimensions__c field. The Javascript also runs properly when we click the link. So, what’s the problem? The problem occurs once the help text is removed from the field. Let’s take a look at what happens if an admin decides they no longer want that help text.

After deleting the help text, the page still seems to work just fine. I can run the page and the popup will be displayed with no value due to the fact that the help text is missing, however the problem occurs when you need to modify the page itself. Let’s go ahead and try to change the label of the link from “Link” to “Show me help text!”. The new code looks like:

At this point, you would expect this to compile with no problem. However, you get the following error instead: Incorrect argument type for function 'JSINHTMLENCODE()'.

What? This page just compiled with no problem. Why are we getting this error all of a sudden? Well, the problem is due to the fact that Salesforce is that $ObjectType.Widget__c.fields.Dimensions__c.inlineHelpText actually returns null at compile rather than an empty string. This causes a big problem for JSINHTMLENCODE() as null is not considered a valid value. So, how do we solve this problem? Well, you need a null check.

The page now compiles correctly and it provides the flexibility for your admin to be able to manipulate the help text without repercussions on future deploys.

Final Thoughts

To be honest, I believe this is a defect on the Salesforce platform, however after speaking with their support, that doesn’t seem to be the case. There is actually a good argument to be made on both sides. Technically, inlineHelpText returning null is valid and null doesn’t need to be an accepted parameter for JSiNHTMLENCODE. This is just the unfortunate side effect of how these pieces of functionality work together. The most important pieces to remember are that inlineHelpText returns null rather than an empty string when no help text is provided and JSINHTMLENCODE() will not compile with a null parameter passed into it. Be proactive to help avoid these issues and utilize null checks where possible. Good luck!