Skip to main content

Bug Tracker

Side navigation

#4314 closed enhancement (patchwelcome)

Opened March 09, 2009 01:48AM UTC

Closed November 17, 2010 02:44AM UTC

Last modified March 14, 2012 02:04PM UTC

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 March 09, 2009 01:48AM UTC.

    the sample html file

Change History (6)

Changed March 09, 2009 07:57AM UTC by dantman comment:1

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.

Changed March 10, 2009 05:39AM UTC by sjkof comment:2

Replying to [comment:1 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.

Changed March 12, 2009 12:03PM UTC by borgar comment:3

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?

Changed April 22, 2009 04:51AM UTC by brandon comment:4

milestone: 1.3.3
owner: brandon
type: bugenhancement

Changed November 17, 2010 02:44AM UTC by dmethvin comment:5

keywords: → needsreview
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.

Changed December 24, 2010 04:31AM UTC by dmethvin comment:6

keywords: needsreview