Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#10563 closed bug (fixed)

jQuery.Event no longer contains the element that matched the selector in event delegation.

Reported by: SlexAxton Owned by:
Priority: blocker Milestone: 1.7
Component: event Version: git
Keywords: delegation Cc: Timmy Willison
Blocked by: Blocking:


Perhaps this was a misunderstanding of mine prior to 1.7, but in my backbone apps, I often will do something like this

events: { '.someElement click' : 'myFunc' }

That essentially just delegates the '.someElement' class from whatever your root element is for that view.

$('#myRoot').delegate( '.someElement', 'click', myFunc);

The important part is that, in backbone, you don't use this to refer to the element you clicked like you might in a pure jQuery app. The context is always the view or the model, etc.

So the myFunc function would usually have something like:

myFunc: function( e ) { console.log( e.currentTarget ); }

And _that_ property of the event object has always pointed at the element that matched the selector. Now it points to the most specific element that you clicked on (usually a sub element of the element that you actually care about). It essentially doesn't differ from event.target as far as I can tell.

I thought event.delegateTarget was what I was looking for, but that also seems to be the root element that the event was actually attached to.

Is there a canonical way to reference this element? If not, should there be?

Change History (7)

comment:1 Changed 12 years ago by SlexAxton

Cc: Timmy Willison added
Component: unfiledevent
Keywords: delegation added
Milestone: None1.7

comment:2 Changed 12 years ago by SlexAxton

The docs for currentTarget seem to imply that unless you explicitly change the context, the two should be the same: http://api.jquery.com/event.currentTarget/

As well as a super-old issue for live seems to imply: http://bugs.jquery.com/ticket/4219

Last edited 12 years ago by SlexAxton (previous) (diff)

comment:3 Changed 12 years ago by dmethvin

Priority: undecidedblocker
Status: newopen

Looks like I broke that in the refactor, but I agree it be the same element as this. The new delegateTarget property should always be the element where the event is attached, as you noted.

comment:4 Changed 12 years ago by Dave Methvin

Resolution: fixed
Status: openclosed

Fix #10563. Ensure event.currentTarget==this if delegated.

Now, event.delegateTarget is always the element where the event was handled, regardless of whether delegated handlers are attached.

Changeset: 84d2307e0e20e9245523731a4450314cc0de6a95

comment:5 Changed 12 years ago by SlexAxton

You are the best, Dave.

comment:6 Changed 12 years ago by SlexAxton

Resolution: fixed
Status: closedreopened

Uh oh, I think this fix might have opened up a new can of worms. Happy to open a separate ticket, but it's still in the same vicinity.


Check your console after clicking on the inner-subcontent.

It logs out for both .inner _and_ .inner-subcontent - where I think it should only log out once (for .inner).

As far as I can tell the .inner-subcontent doesn't match the selector, and therefore should not trigger any callback.

In case it ends up mattering, I've pretty much only tested this in Chrome Dev Channel (16ish) and Canary.

Last edited 12 years ago by SlexAxton (previous) (diff)

comment:7 Changed 12 years ago by dmethvin

Resolution: fixed
Status: reopenedclosed

No, these are different worms. It's erroneously matching the "inner" in "inner-subcontent". I'll open a separate ticket.

Note: See TracTickets for help on using tickets.