Okay, after doing some digging through the source, I believe I can answer your question definitively.
The reason dojo.stopEvent()
doesn't work, but return false
does, is entirely due to how dijit.form.Button
is coded. If you're interested, it's time for a little field trip. Keep your hard hats on.
When a dijit.form.Button
is clicked...
- The button's
_onButtonClick
method is invoked. (This is hooked up in the template, to the special ondijitclick
event which captures not only mouse click but also certain keypresses, for a11y purposes.)
- The
_onButtonClick
method first invokes the _onClick
method, which, presuming the button is not disabled (which it's not in this case), invokes and returns the result of the onClick
method. This is of particular interest since it's the method you're overriding!
- Coming back to
_onButtonClick
, if _onClick
returned precisely false
(e.g. if your onClick
handler returned false
), _onButtonClick
immediately bails out. This is why returning false makes your code work as desired. But what happens if it doesn't bail out there? Let's follow the trail further...
- Next,
_onButtonClick
checks whether this button not a descendant of an actual HTML form, but is a descendant of a widget with an _onSubmit
method (duck-typing). I'm assuming that in your case it is inside a real form (dijit.form.Form
counts), so we'll skip over this. (I am under the impression that this code path wouldn't actually end up submitting, whereas yours apparently does.)
- One final condition is checked: if the button has a
valueNode
defined (it does), the click
method of this node is invoked. Unfortunately, this produces an entirely new event object on an invisible input type="submit"
node under your form, and thus anything you tried to tell the original event is rendered immaterial, and the form goes on to submit! This is why dojo.stopEvent
did not work - this code in dijit.form.Button
pays it absolutely no heed.
I cooked this up as a somewhat-limited proof of concept (be sure to open firebug/etc. to get the logs): http://jsfiddle.net/Bf5H8/
Perhaps this is something that should be logged as a bug, but I suppose the initial thought may have been that supporting the well-known return false
mechanism would be enough.
All this being said, it's quite possible that overriding onSubmit of the form is more in-line with your interests than overriding the button's onClick anyway (as S.Jones suggested), but at least this should solve the mystery.