Often, I'll add an event handler to a dojo widget. For example, a handler for the change event. Then, something in my code will trigger the change event - but I don't know what. So, normally you just set a breakpoint in your favorite debugger, and then look at the call stack, and you can quickly trace what caused the event to fire. But, often my active call stack ends at dojo's lang.hitch, which I'm guessing is because dojo passes the function to window.setTimeout, and so most of the useful information in the call stack is gone when the func gets executed on the js event queue.
Here's a small executable sample.
<b id="cb"></b>
<script src="//ajax.googleapis.com/ajax/libs/dojo/1.9.3/dojo/dojo.js"></script>
<script>
require(["dijit/form/CheckBox", "dojo/domReady!"], function(CheckBox){
var checkBox = new CheckBox({
onChange: function(b){
console.log(b);
}
}, "cb");
// manually trigger change event.
// i want to be able to see this line in the debuggers call stack.
checkBox.set("checked", true);
});
</script>
Is there an easy way to overcome this annoying debugging impediment? Like maybe, a setting that tells dojo not to execute event handlers via setTimeout?
In this case, it appears that _WidgetBase.js defer() is the one calling setTimeout, but I know I encounter this issue very frequently in dojo, and was hoping there's a better way than editing their source.
