This is just a heads up for a rather strange behaviour in the ASP.NET validation scheme.

I happened to notice that when I try to submit a form via postback, and a client-side validation error occurs (e.g. a RequiredFieldValidator fires up on an empty field), then the if next postback doesn't trigger a validation, it doesn't go through at all. This is particularly baffling when ASP.NET AJAX (i.e. UpdatePanels) is at play, as the XHR request is never fired. Ever.

Searching a bit on the web, I've found that the client validation scheme exposes a variable, named Page_BlockSubmit, that when true, does exactly that: Blocks the form submit. It appears that it is used like so:

function Page_ClientValidate(validationGroup) {
    ...
    Page_BlockSubmit = !Page_IsValid;
    return Page_IsValid;
}

And then, the next postback fails if it doesn't trigger a validation (e.g. a SelectedIndexChanged event) because the variable is reset in ValidatorCommonOnSubmit, not in __doPostBack:

function ValidatorCommonOnSubmit() {
    ...
    var result = !Page_BlockSubmit;
    ...
    Page_BlockSubmit = false;
    return result; 
}

And since the SelectedIndexChanged event doesn't trigger a validation, the Page_BlockSubmit retains its value as true.

This can get particularly awkward for the developer.

A common way to overcome the issue is to explicitly set the variable to false before the call to __doPostBack.