gistfile1.js

$("#foo").click(function(e){
   if (e.clientX) {
      // native mouse click
   }
   else {
      // triggered mouse click
   }
});

Ugh... would be awesome if there was information about where the mouse IS when the click was triggered.

I'm not a fan of programatically triggering native events. I think you should have a separate custom event (bound to same handler) for triggered events.

An example similar to that in the jQuery .trigger documentation and the W3C documentation.

// moar lame
$("#foo").trigger($.extend($.Event("click"), { clientX: 20, clientY: 30 }));

// moar win
$("#foo").trigger({ type : 'click', clientX: 20, clientY: 30 } );

@jdalton other than test frameworks, i would consider that kind of code (and the ability to do it in JavaScript and jQuery, etc) wrong and evil. This is a big reason why I don't think native events should be trigger'able.

Is this "evil" like eval evil, or with statement evil, or document.write evil?
If you feel so strongly about this nefarious terrorist API I guess you can take it up with the W3C and submit a jQuery ticket.

Dunno about the evilness of this one, but it's another way to do that..

$("#foo").trigger( { type : 'click', clientX: 20, clientY: 30 } );

@jdalton it's the document.write() kind of evil, and it must die.

someone please explain to me, other than test frameworks (automation), why is it a good thing to simulate a native event including simulating inaccurate mouse coordinates?

I've come across a seemingly valid use case when creating bookmarklets and extensions interacting with existing, scope-protected widgets using mouse/keyboard input. Not something you'd do everyday, but it would probably be impossible without the ability to simulate native events, no?

@krawaller -- i don't deny that might be a valid (but very niche) case... but it fits closely with "automation".

what i'm opposed to is that people use this technique as a general coding pattern... like: "i have a button i want users to click on, and also i want to have another action that can pretend to click the button (like enter), so what i'm gonna do is code behavior against click only and then hide the detail that something else can also fire that click."

in my opinion, this is an anti-pattern, because you are creating a connection between two pieces of code that is much harder to decipher and debug. it's kinda like putting event handler code inside inline attributes, mixing markup and code. does it work? yeah. but is it a good idea? hell no.

instead, you could/should have bound two separate events to the same handler. that would accomplish the same goal and be a lot cleaner and more understandable/maintainable code.

Firing events can be used in cross-browser event delegation solutions to normalize inconsistent event bubbling.
Prototype uses DOM events, and their firing, to support custom event's that piggyback off of real events.
This has some advantages like if 1 handler fails the others will continue to execute.

instead, you could/should have bound two separate events to the same handler. that would accomplish the same goal and be a lot cleaner and more understandable/maintainable code.

You will end up having issues syncing the two events when one is told to stop bubbling and the other is unaware.
And what do you think would be used to fire these secondary custom events? That would be the same API you called evil :D

@jdalton - triggering events is definitely not evil. in my opinion, triggering a native event is bad. triggering a native event and pretending to be that native event with bogus information like fake mousex/mousey values is evil.

@getify Indeed - as a general coding pattern, it's really bad practice. However, the solution is not to remove the support à la

i would consider that kind of code (and the ability to do it in JavaScript and jQuery, etc) wrong and evil

We shouldn't remove democracy just because it lets us do evil, right? ;)

@krawaller -- i mean, i understand your point. not necessarily saying it should be removed, but it should be avoided under almost all cases, just like what crockford says about the "good parts" and "bad parts" -- i definitely consider that a "bad part".

btw, there are some things that are so evil they should be removed... like "document.write"... my new banner: "document.write() must die". :)