We Keep Coding

Insert event into browser event queue?

I don't have a particular use-case for this, so I'm open to anyone proving that there is none, however, I've been wondering if the event model of JavaScript in the browser allows code to insert an event into the event queue, so that it will be processed after all the other events already present have been handled.
I found EventTarget.dispatchEvent but that does not fit what I think I might want for two reasons:
It seems to be synchronous, so it will be processed before all other events already in the queue which "feels wrong".
I have to have a specific EventTarget instance to send it to, which also feels like a limitation. If I want the loosest coupling I should not have to know the target (indeed, I believe I might want more than one target to receive this event, and these targets need not necessarily be in a containment hierarchy in the way that DOM Elements/Nodes are.)
Is there some part of the API that I've failed to find?
Is there perhaps provably no value in this?
Or is there perhaps a reliable platform-independent way to achieve everything this concept might achieve?

Using Dojo's onHashChange without topic?

Dojo's tutorial calls for using topic.subscribe to catch the onHashChange event - use of topic is heavy and is frowned upon within the organization, is there any way I can use dojo/on to catch and handle onHashChange?

You could find out where the onHashChange publish event is triggered within the dojo / hash code and use dojo/stateful to link to that property.
Dojo already uses topic.publish to publish the change. So you are already make unwanted use of the bad (?) topic module. If you don't want to use it, maybe you have to look into the dojo/hash module and check out how they extract the hash change from the browser...

addeventlistener for 'keypress' = captcha alternative?

Am I right in thinking that spam bots can't simulate the 'keypress' event, and thus I can't get spammed if I require a keypress for each field in my contact form before being able to submit it?
Is this a good alternative to captcha, etc. if I don't care whether or not my viewers have JavaScript enabled?
Wizards, set me right.

I'm unsure if they can generate the keypress event "natively" (I think you might be right that they can't, but it wouldn't surprise me to learn that there's some edge case whereby this is possible).
However, I don't think they would have a problem merely executing element.onkeypress() directly. If the bot can determine that it needs to press a key to advance, then what that actually boils down to is that a particular event handler method needs to be invoked - and the bot can do the latter. It can create its own fake Event object too containing the keycode, and then pass this in and/or set it on window.event.
In theory you might be able to detect this by being very strict about instrospecting the event object in your handler. I don't think that the bot would easily be able to create a native-equivalent event object, so perhaps by inspecting the prototype chain you could distringuish between the two. However, this would almost certainly be too fragile for general use, and is not going to reliably work across different browsers/environments/plugins/etc.
Thus I don't think this is a fruitful path, because you can't tell in an event handler whether the event is "real" or not. Browser-native code is different, since bots cannot actually trigger a click event, but within Javascript I don't see a simple way to prevent your method from simply being called.

The current implementations of spambots might not be able to do that. But it's not that hard to simulate keypresses. If you're only a small website the bot author might not do the work to circumvent your system, but if it large enough for the auther to care your system will be broken really quick.

Controlling the order that event handlers / listeners are executed in

Once again the IE Monster has hit me with an odd problem.
I'm writing some changes into an asp.net site I inherited a while back. One of the problems is that in some pages there are several controls that add Javascript functions as handlers to the onload event (using YUI if that matters). Some of those event handlers assume certain other functions have been executed.
This is well and good in Firefox and IE7 as the handlers seem to execute in order of registration. IE8 on the other hand does this backwards.
I could go with some kind of double-checking approach but given the controls are present in several pages I feel that'd create even more dependencies. So I've started cooking up my own queue class that I push the functions to and can control their execution order. Then I'll register an onload handler that instructs the queue to execute in my preferred order.
I'm part way through that and have started wondering 2 things:
Am I going OTT?
Am I reinventing the wheel?
Anyone have any insights? Any clean solutions that allow me to easily enforce execution order?

I could not find any Standard that would define the call-order of events. This is not an issue this is pure anarchy :D
Also there's hundreds of independent implementations of this pattern, so it is unlikely that they would behave coherently anytime soon.
So yes you're off on your own.
The cleanest and most compatible approach I have, involves registering just one event-handler :D That way the native order becomes irrelevant.
Now the trick is to add your own predictable event-management on top of that - using a library, extending with nodeJS's version for example, depending on your requirements.
Note that JS gives you the freedom to just override the prototype-derived functions, so another possibility is something like this:
function eventify(element){
element._event = {}
element.on = element.addListener = function(evt,fn){ ... }
element.off = element.removeListener = function(evt,fn){ ... }
element.emit function(evt,args...){ ... do it the right way ... }
}
So maybe you are a little off track in considering queues and locking-mechanisms :)

Unobtrusive Javascript Obfuscates Event Handling

You know what I liked best about obtrusive javascript? You always knew what it was going to do when you triggered an event.
<a onclick="thisHappens()" />
Now that everybody's drinking the unobtrusive kool-aid it's not so obvious. Calls to bind events can happen on any line of any number of javascript file that get included on your page. This might not be a problem if you're the only developer, or if your team has some kind of convention for binding eventhandlers like always using a certain format of CSS class. In the real world though, it makes it hard to understand your code.
DOM browsers like Firebug seem like they could help, but it's still time consuming to browse all of an element's event handler properties just to find one that executes the code you're looking for. Even then it usually just tells you it's an anonymous function() with no line number.
The technique I've found for discovering what JS code gets executed when events are triggered is to use Safari's Profiling tool which can tell you what JS gets executed in a certain period of time, but that can sometimes be a lot of JS to hunt through.
There's got to be a faster way to find out what's happening when I click an element. Can someone please enlighten me?

Check out Visual Event... it's a bookmarklet you can use to expose events on a page.

If you're using jQuery you can take advantage of its advanced event system and inspect the function bodies of event handlers attached:
$('body').click(function(){ alert('test' )})
var foo = $('body').data('events');
// you can query $.data( object, 'events' ) and get an object back, then see what events are attached to it.
$.each( foo.click, function(i,o) {
alert(i) // guid of the event
alert(o) // the function definition of the event handler
});
Or you could implement your own event system.

To answer your question, try using the Firebug command line. This will let you use JavaScript to quickly grab an element by an ID, and then iterate through its listeners. Often, if used with console.log, you'll even be able to get the function definitions.
Now, to defend the unobtrusive:
The benefit I find in unobtrusive JavaScript is that it is a lot easier for me to see the DOM for what it is. That said, I feel that it is generally bad practice to create anonymous functions (with only few exceptions). (The biggest fault I find with JQuery is actually in their documentation. Anonymous functions can exist in a nether-world where failure does not lead to useful output, yet JQuery has made them standard.) I generally have the policy of only using anonymous functions if I need to use something like bindAsListener from Prototype.
Further, if the JS files are properly divided, they will only be addressing one sub-set of the DOM at a time. I have an "ordered checkbox" library, it is in only one JS file which then gets re-used in other projects. I'll also generally have all of the methods of a given sub-library as member methods of either a JSON object or a class and I have one object/class per js file (just as if I were doing everything in a more formalized language). If I have a question about my "form validation code", I will look at the formValidation object in formvalidation.js.
At the same time, I'll agree that sometimes things can become obtuse this way, especially when dealing with others. But disorganized code is disorganized code, and it is impossible to avoid unless you are working by yourself and are a good programmer.
In the end, though, I would rather deal with using /* */ to comment out most of two or three js files to find misbehaving code, then go through the HTML and remove the onclick attributes.

Calling it "kool-aid" seems unfair. DOM Level 2 events solve specific problems with inline event handling, like the conflicts that always result. I don't look back to writing code to use window.onload that has to check whether someone else has assigned it before, and sometimes having it overriden by accident or out of sloppiness. It also ensures a better separation of the structure (HTML) and behaviour (JS) layers. All in all, it's a good thing.
Regarding debugging, I don't think there's any way to solve the event handlers being anonymous functions, other than nagging the authors to use named functions where possible. If you can, tell them that it produces more meaningful call stacks and makes the code more maintainable.

One thing: you shouldn't be able to see what will happen in JavaScript by looking at the HTML code. What nuisance is that? HTML is for structure.
If you want to check what events are bound to certain elements, there's a bookmarklet called visual event for now, and firebug 1.6 (IIRC) will have some sort of event inspector.