Returning false from Client-Side Handler does not Prevent Postback

Question

I have the following button on a WebForms page:

<asp:Button ID="btnNewProgramNext" runat="server" Text="Next &gt;&gt;" />

And I have the following javascript/jquery to handle it's event.

$('#<%= btnNewProgramNext.ClientID %>').on('click', function (e) {
    var errorMessage = '';
    var ok = false;
    var newCompany = $('#<%= NewCompanyMode.ClientID %>').val();
    if (newCompany == 1) {
        if (!$('#<%= txtProgramCompanyName.ClientID %>').val())
            errorMessage = 'You must enter a company name.';
        else if (!$('#<%= txtContactFirstName.ClientID %>').val())
            errorMessage = 'You must enter a contact first name.';
        else if (!$('#<%= txtContactLastName.ClientID %>').val())
            errorMessage = 'You must enter a contact last name.';
        else
            ok = true;
    }
    else {
        // Do something else
        ok = true;
    }
    $('#newProgramErrorMessage').text(errorMessage);
    return ok;
});

The problem is, when this handler returns false (either when ok is false, or when I change the last line to return false), the postback still occurs.

Is there any trick to preventing a postback from javascript? I expected this to work.

score 2 · Accepted Answer · answered Oct 01 '13 at 16:39

You want e.preventDefault() in order to cancel the button click event.

$('#<%= btnNewProgramNext.ClientID %>').on('click', function (e) {
    var errorMessage = '';
    var ok = false;
    var newCompany = $('#<%= NewCompanyMode.ClientID %>').val();
    if (newCompany == 1) {
        if ($('#<%= txtProgramCompanyName.ClientID %>').val() == "")
            errorMessage = 'You must enter a company name.';
        else if ($('#<%= txtContactFirstName.ClientID %>').val() == "")
            errorMessage = 'You must enter a contact first name.';
        else if ($('#<%= txtContactLastName.ClientID %>').val() == "")
            errorMessage = 'You must enter a contact last name.';
        else
            ok = true;
    } else {
        // Do something else
        ok = true;
    }
    if (!ok) {
        e.preventDefault();
        $('#newProgramErrorMessage').text(errorMessage);
    }
    // else everything is valid, so post back to server.
});

There sure seems to be a lot of confusing information about this out there. According to the main answer to [this question](http://stackoverflow.com/questions/1357118/event-preventdefault-vs-return-false), "return false from within a jQuery event handler is effectively the same as calling both e.preventDefault and e.stopPropagation on the passed jQuery.Event object." — Jonathan Wood, Oct 01 '13 at 16:42
Information you stated is correct for regular html control. In OP, you are using ASP.Net Sever control which has own javascript to postback to server. Ideally, you want to use ClientClick if you use ASP.Net Server control (which ***Garrison Neely*** answered). Here is the [example](http://stackoverflow.com/a/17579534/296861) — Win, Oct 01 '13 at 16:47

score 1 · Answer 2 · answered Oct 01 '13 at 16:23

1

Why don't you try hooking it up via the ClientClick property instead of using jQuery to subscribe to the click event. That may be the route ASP.NET uses to determine whether to kill the PostBack.

answered Oct 01 '13 at 16:23

Garrison Neely

3,238
3
27
39

Using `OnClientClick` does in fact work. Still looking into why I can't use jQuery here. – Jonathan Wood Oct 01 '13 at 16:32
I think it's obvious. I bet by default, unless `OnClientClick` is declared in the markup, it returns `true`. ASP.NET WebForms was created before jQuery, and wouldn't know to look in any other path. Just declare the JavaScript as a discrete function and call it from `OnClientClick`. – Garrison Neely Oct 01 '13 at 16:36
The part that is not obvious to me is how does returning false work in regular HTML? It blocks further processing on the action. It does not depend on WebForms. So why does it require WebForms here? – Jonathan Wood Oct 01 '13 at 16:38

Returning false from Client-Side Handler does not Prevent Postback

2 Answers2