Categories
dom-events event-handling event-propagation javascript jquery

event.preventDefault() vs. return false

3179

When I want to prevent other event handlers from executing after a certain event is fired, I can use one of two techniques. I’ll use jQuery in the examples, but this applies to plain-JS as well:

1. event.preventDefault()

$('a').click(function (e) {
    // custom handling here
    e.preventDefault();
});

2. return false

$('a').click(function () {
    // custom handling here
    return false;
});

Is there any significant difference between those two methods of stopping event propagation?

For me, return false; is simpler, shorter and probably less error prone than executing a method. With the method, you have to remember about correct casing, parenthesis, etc.

Also, I have to define the first parameter in callback to be able to call the method. Perhaps, there are some reasons why I should avoid doing it like this and use preventDefault instead? What’s the better way?

8

  • 178

    Note that jQuery’s preventDefault does not prevent other handers from executing. That’s what stopImmediatePropagation is for.

    Aug 31, 2009 at 12:22

  • 19

    @CrescentFresh, it does prevent other (subsequently bound) handlers from executing… on the DOM node the event is fired on. It just doesn’t prevent propagation.

    Oct 17, 2011 at 2:51

  • 40

    These are not “two methods of stopping event propagation?” e.preventDefault(); prevents the default action, it does not stop event propagation, which is done by e.stopPropagation().

    Jan 9, 2012 at 1:44

  • 27

    This question and its answers are about jQuery. If you came here searching for a plain javascript answer, see event.preventDefault() vs. return false (no jQuery)

    – Oriol

    Sep 28, 2013 at 21:23

  • 5

    This answer has a table explaining it all stackoverflow.com/a/5302939/759452

    – Adrien Be

    Apr 16, 2014 at 7:20

2947

+500

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.

e.preventDefault() will prevent the default event from occuring, e.stopPropagation() will prevent the event from bubbling up and return false will do both. Note that this behaviour differs from normal (non-jQuery) event handlers, in which, notably, return false does not stop the event from bubbling up.

Source: John Resig

Any benefit to using event.preventDefault() over “return false” to cancel out an href click?

4

  • 134

    return false from a DOM2 handler (addEventListener) does nothing at all (neither prevents the default nor stops bubbling; from a Microsoft DOM2-ish handler (attachEvent), it prevents the default but not bubbling; from a DOM0 handler (onclick="return ..."), it prevents the default (provided you include the return in the attribute) but not bubbling; from a jQuery event handler, it does both, because that’s a jQuery thing. Details and live tests here

    Nov 30, 2011 at 13:09


  • 13

    It would be helpful to define “Propagation” and “Default” here. I for one keep confusing them. Is this correct? Propagation = my code (JavaScript event handlers for parent elements). Default = browser code (links, text selection, etc.)

    – Bob Stein

    Jul 28, 2013 at 14:49

  • 5

    what is really mean by bubbling? example?

    Aug 17, 2016 at 10:59

  • 6

    +1 for noting that return false does not stop event propagation in non-jQuery event handlers. i.e. <a href="#" onclick="return false">Test</a> does not stop the event from bubbling up.

    – Doug S

    Aug 21, 2016 at 2:42


452

From my experience, there is at least one clear advantage when using event.preventDefault() over using return false. Suppose you are capturing the click event on an anchor tag, otherwise which it would be a big problem if the user were to be navigated away from the current page. If your click handler uses return false to prevent browser navigation, it opens the possibility that the interpreter will not reach the return statement and the browser will proceed to execute the anchor tag’s default behavior.

$('a').click(function (e) {
  // custom handling here

  // oops...runtime error...where oh where will the href take me?

  return false;
});

The benefit to using event.preventDefault() is that you can add this as the first line in the handler, thereby guaranteeing that the anchor’s default behavior will not fire, regardless if the last line of the function is not reached (eg. runtime error).

$('a').click(function (e) {
  e.preventDefault();

  // custom handling here

  // oops...runtime error, but at least the user isn't navigated away.
});

2

  • 71

    Whilst true, the opposite behaviour is often preferable when doing progressive enhancement (which I think is probably the most likely reason to be overriding a default action)

    Apr 27, 2012 at 22:53

  • Both are ways to block the default behaviour of an event, it’s just a matter of what problem you’re trying to solve.

    Feb 3, 2020 at 21:00

111

This is not, as you’ve titled it, a “JavaScript” question; it is a question regarding the design of jQuery.

jQuery and the previously linked citation from John Resig (in karim79’s message) seem to be the source misunderstanding of how event handlers in general work.

Fact: An event handler that returns false prevents the default action for that event. It does not stop the event propagation. Event handlers have always worked this way, since the old days of Netscape Navigator.

The documentation from MDN explains how return false in an event handler works

What happens in jQuery is not the same as what happens with event handlers. DOM event listeners and MSIE “attached” events are a different matter altogether.

For further reading, see attachEvent on MSDN and the W3C DOM 2 Events documentation.

4

  • 6

    @rds That says “preventDefault doesn’t stop further propagation of the event through the DOM. event.stopPropagation should be used for that.”

    – Garrett

    Jul 24, 2011 at 23:40

  • An answer on a closely-related question alleges that prior to HTML 5, returning false from an event handler wasn’t specced as doing anything at all. Now, maybe that’s an incorrect interpretation of the (hard to understand) spec, or maybe despite it not being specced literally all the browsers interpreted return false the same as event.preventDefault(). But I dunno; it’s enough to make me take this with a pinch of salt.

    Jan 24, 2016 at 0:13


  • 11

    I hate how every javascript search result in google is actually about jQuery, +1

    Oct 11, 2016 at 21:26

  • He has tagged it as both JavaScript and jQuery, and both are correct. jQuery is merely a sub-set of JavaScript, not its own language.

    – ProfK

    Jan 28, 2020 at 5:26