CompareValidator Bug: Remember to Call Page.IsValid?
One of the common mistakes developers make when working with Web Forms pages is using client-side validation, while not checking the validation result on server-side postback.
Now, in other cases you should be fine right? Not really, no. I’ve just found a little bug in CompareValidator. Let’s try this:
1 2 3 4
And on the server side:
1 2 3 4
There is an obvious problem. Page.IsValid is not checked to ensure the submitted form is valid. With built-in validators and JS enabled this shouldn’t be a problem.
However the ComapreValidator is a bit picky. It works fine for input like 2000-10-10, or 2000-00-00. Also writing for example 20-10-10 validates correctly and parsing it would not be a problem.
Surprisingly though date 25-25-25, which is not valid causes the JS validation to fail inside ScripResource.axd with an exception and postback is not stopped even though the form is not valid. So what happens then? Event handler throws an exception where it tries to parse the input. For that reason always remember to write your handlers like
1 2 3 4 5 6 7