Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Doesn't a return without argument return false and thus have the same effect as preventDefault()? That would explain the difference, since the events are not "bubbling up".


Return without a value returns undefined, which is falsy but not false.


As many pointed out, I was wrong. An empty return doesn't equal a false return.

Neither does jQuery interpret a return of undefined as a stopPropagation, as this fiddle shows:

http://jsfiddle.net/6UGN8/


Have you been explicitly returning true all this time?


I think `function(){}` and `function(){return;}` are equivalent, at least functionally... Still can't explain the time difference, though.


return without return false is just like breaking out of a method i think.. The events would still bubble since false isn't returned


An empty return statement has the return value undefined which is falsy. As lukashed said jQuery most likely interprets this as false and stop propagation of the event, however using an empty function also has the return value undefined so both cases stops propagation.

Both versions have the same return value as illustrated by this fiddle http://jsfiddle.net/QHxJ3/


> As lukashed said jQuery most likely interprets [undefined] as false and stop propagation of the event...

No, it doesn't. jQuery uses a strict test for false and does not stop propagation for other falsy return values from an event listener.

The documentation could be more clear on this point. All it says is: "Returning false from an event handler will automatically call event.stopPropagation() and event.preventDefault()."

http://api.jquery.com/on/#event-handler

Here's the code that does this check:

  if ( ret !== undefined ) {
      if ( (event.result = ret) === false ) {
          event.preventDefault();
          event.stopPropagation();
      }
  }
https://github.com/jquery/jquery/blob/master/src/event.js#L3...

Reading that code, it almost seems redundant at first to have a !== undefined check when the === false is already a strict comparison. But there is that assignment hidden inside the if expression. So the code is really the same as this more clearly written version:

  if ( ret !== undefined ) {
      event.result = ret;
      if ( ret === false ) {
          event.preventDefault();
          event.stopPropagation();
      }
  }
This would also have the same effect:

  if ( ret !== undefined ) {
      event.result = ret;
  }
  if ( ret === false ) {
      event.preventDefault();
      event.stopPropagation();
  }
These all do the same thing: set event.result only if ret is not undefined, and then call preventDefault and stopPropagation only if ret is false (and not just a falsy value).


Interesting, I would have never thought the js interpreter would interpret both as being === even though the two functions are different.


The two functions are different, but their return values are identical. The === is comparing the return values.

Consider this example:

  function onePlusOne() { return 1 + 1; }
  function two() { return 2; }

  alert( onePlusOne === two );  // false, not the same function
  alert( onePlusOne() === two() );  // true, same value




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: