‘WebForm_PostBackOptions’ is undefined, Validators and WebResource.axd

If you have ever come across the JavaScript error message ‘WebForm_PostBackOptions’ is undefined in your travels through the world of ASP.NET, you will know just what a pain it is. Hopefully, the following will go some way to helping resolve it:

Firstly, when does it happen?

You will typically see this error message when you display an ASPX page that contains a Validator (for example a RequiredFieldValidator), some controls and a control that causes a postback to the server. The JavaScript error message is displayed when you invoke the postback and the client controls are validated; it may just be displayed and then continue to allow the postback; it may be displayed and actually prevent the postback altogether.

Secondly, why does it happen?

Validators can use client side JavaScript to validate the controls without posting back to the server – this give a far better user experience. Obviously, when an error occurs, quite a large amount of JavaScript is required to locate the bound control, perform the validation, display an error message in the correct location on the screen and prevent the postback. It would be good if this JavaScript were cached on the client rather than being added to the HTML directly.

One way of caching the JavaScript is to place it into a separate .js file. This file can then be referenced directly in the HTML, downloaded and cached on the client. Using this approach, the .js file would need to be available on the web server for download, which isn’t the end of the world, but does involve a management / deployment overhead.

ASP.NET 2.0 introduced the concept of the WebResource.axd handler (i don’t intend to go into detail as to what this handler is/does, but more information can be found here). This handler can be used to ‘look inside’ assemblies for resources such as images, strings or files such as JavaScript or CSS files. This provides a neat solution to deployment and reuse as suddenly our Validators become a single assembly that contains all of the client and server side logic.

If you look at the HTML that is generated when a Validator is on an ASPX page, and EnableClientScript = True, you will see that a reference to a script file is added to the output, an example of which is shown below. This reference points back to the client side JavaScript required to perform validation. The reason we see the ‘WebForm_PostBackOptions’ is undefined error is because there has been a problem downloading the JavaScript file from the server – of course this isn’t highlighted in the browser and so isn’t immediately obvious.

<script type="text/javascript" src="/WebSite1/WebResource.axd?d=VqPlh_vtOSm3C5JXuOJFWDaG0dm1LwfB7--yzOqTmJw1&t=633210572006621533"></script>

How can we find out what the exact problem is?

This is actually very difficult. There is no tracing on the server for the WebResource.axd handler so we do not know if there is a problem obtaining the requested resource. Similarly, a lot of the initial errors, such as the script file not being downloaded, are swallowed by the browser. However, it is possible to place the WebResource.axd link directly into the browser and see what is returned. If everything is OK, the returned content will be a JavaScript file; otherwise the return value should give us an idea as to the cause of the problem.

Typically, the error is due to the Web Server being configured to perform HTML parsing on returned content and the contents of the AXD response are being altered. For example, there may be a handler that adds a company header and footer to the response, which in turn invalidates the JavaScript. Alternatively, there may be some form of compression that takes place on the output, which in turn invalidates the content.

Hopefully, armed with this information, you should be able to track down the problem. If all else fails, you can either switch EnableClientScript = False, to prevent the addition of the WebResource.axd script link to the HTML – you will need to perform server side validation and suffer a roundtrip to the server though. Alternatively, you will need to write your own validation routine.