Bug Tracker

Opened 10 years ago

Closed 9 years ago

Last modified 7 years ago

#4314 closed enhancement (patchwelcome)

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

Reported by: sjkof Owned by:
Priority: major Milestone:
Component: event Version: 1.3.2
Keywords: Cc:
Blocked by: Blocking:

Description

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.

Attachments (1)

file.htm (1.1 KB) - added by sjkof 10 years ago.
the sample html file

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by sjkof

Attachment: file.htm added

the sample html file

comment:1 Changed 10 years ago by 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.

comment:2 in reply to:  1 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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?

comment:4 Changed 10 years ago by brandon

Milestone: 1.3.3
Owner: brandon deleted
Type: bugenhancement

comment:5 Changed 9 years ago by dmethvin

Keywords: needsreview added
Resolution: patchwelcome
Status: newclosed

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.

comment:6 Changed 8 years ago by dmethvin

Keywords: needsreview removed
Note: See TracTickets for help on using tickets.