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:	timmywil
Blocked by:		Blocking:

Description

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?

Attachments (0)

Change History (7)

Changed October 24, 2011 06:38AM UTC by SlexAxton comment:1

cc:	→ timmywil
component:	unfiled → event
keywords:	→ delegation
milestone:	None → 1.7

Changed October 24, 2011 07:55AM UTC by SlexAxton comment:2

_comment0:	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/] → 1319443114370932

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

Changed October 24, 2011 01:39PM UTC by dmethvin comment:3

priority:	undecided → blocker
status:	new → open

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.

Changed October 24, 2011 03:22PM UTC by Dave Methvin comment:4

resolution:	→ fixed
status:	open → closed

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

Changed October 24, 2011 06:40PM UTC by SlexAxton comment:5

You are the best, Dave.

Changed October 24, 2011 08:53PM UTC by SlexAxton comment:6

_comment0:	Uh oh, I think this fix might hav opened up a new can of worms. Happy to open a separate ticket, but it's still in the same vicinity. \ \ http://jsfiddle.net/SlexAxton/u3NyG/1/ \ \ 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. → 1319489638655580
_comment1:	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. \ \ http://jsfiddle.net/SlexAxton/u3NyG/1/ \ \ 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. → 1319489818933804
_comment2:	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. \ \ http://jsfiddle.net/SlexAxton/u3NyG/1/ \ \ 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 (14?) and Canary. → 1319489850888571
resolution:	fixed
status:	closed → reopened

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.

http://jsfiddle.net/SlexAxton/u3NyG/1/

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.

Changed October 24, 2011 09:02PM UTC by dmethvin comment:7

resolution:	→ fixed
status:	reopened → closed

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

Side navigation

#10563 closed bug (fixed)