trigger() will not fire events that are not added by jquery's function

[sjkof]

if we use attachEvent(in IE) or addEventListener(in FireFox) to add events, then trigger() will not fire those events. But if we use jquery's function to add events, then the events can be triggered correctly.

[sjkof]

the sample html file

[dantman]

jQuery handles bubbling on it's own and tracks events on it's own. I know there is no reliable way to ask the browser what events have been bound to a node. I don't believe it's possible for jQuery to trigger anything but it's own events without doing something that gets rid of custom events, or has issues working in some supported browsers.

[sjkof]

Replying to dantman:

I know there is no reliable way to ask the browser what events have been bound to a node.

Yes, you are right. But we can trigger the events bounded to a node whether we know them exactly or not. In fact, I have already used triggering event manually in my sample html file. (the button named "otherTrigger")

jQuery handles bubbling on it's own and tracks events on it's own.

If this is the design of jquery, maybe it is acceptable.

[borgar]

I have already used triggering event manually in my sample html file. (the button named "otherTrigger")

A quick thought on this. Custom triggering is hard because fireEvent / dispatchEvent will release the bubble down the tree and event handlers will get triggered in the wrong order. However, dispatchEvent + cancelBubble is by spec supposed to run all event handlers on the element and then stop. That is, cancelling the bubble should not cancel running handlers on an element until they have all been run.

This would enable a trick like this:

function popper(e) { e.cancelBubble = true; }
element.addEventListener( popper );
try {
  var ev = document.createEvent( "UIEvents" );
  ev.initEvent( 'keydown', true, true );
  inputElement.dispatchEvent( ev );
} 
finally {
  // handler MUST be cleaned off
  element.removeEventListener( popper );
}

I have no idea if this actually works, what IE does, or if the kind of slowdown this would cause is acceptable to the event handling in jQuery, but it might work toward a solution?

[dmethvin]

So the only reason I can think that this would be important is for retrofitting jQuery into a page that used a lot of native event hookups. This would seem to be on the decline so it's most likely not worth the effort to develop and test such code. Note that jQuery does support events defined via the DOM0 way with an .onXXX handler.