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

[SlexAxton]

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?

[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/

[dmethvin]

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.

[Dave Methvin]

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

[SlexAxton]

You are the best, Dave.

[SlexAxton]

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.

[dmethvin]

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