From my tests, this issue occurs in Chrome and IE9, but not FF. Windows Server 2008.

Regarding the guidelines to use jsfiddle; I attempted to use jsfiddle instead of jsbin, but I could not get the SVG to render in jsfiddle.

Thanks for the clear explanation and test case!

Delegated events have never worked on SVG elements since they have no DOM methods we can use. I opened a documentation ticket for that. https://github.com/jquery/api.jquery.com/issues/211

In 1.8+ jQuery throws an error on this case in Sizzle, but prior to that it silently ignores delegate clicks within SVG elements. I think we should do the latter, both for backcompat and because delegated event handlers have no way of protecting themselves against events that bubble up from within SVG compartments. @gibson042 or @timmywil?

Here's what's going on:

1. For delegated events, jQuery.event.dispatch checks every element from the event target up to the delegate to see if one matches the delegation selector.

2. When possible, that check takes a fast approach that passes a seed set to Sizzle

3. Sizzle runs Expr.filter matchers against the seed, which in many cases (including this one) assume the availability of .getAttribute or other DOM methods

4. However, the SVGElementInstance elements generated by SVG use elements have a rather limited interface which does not include any of those methods, so passing them to a matcher is almost guaranteed to throw.

If wontfix is not an acceptable resolution for the reasons you mentioned, we should do... something... in dispatch. The most user-friendly method would be similar to cur = cur.correspondingUseElement || cur within the cur = event.target loop. !cur.nodeType (since parentNode points to the wrong place anyway) is smaller, but would mean losing the event entirely.

Either way, there will be a (small) performance hit in this hot path from the additional property access on cur.

Fixing the problem in .dispatch() does make the most sense. It would be a shame to mess up the matchers with this, since we really shouldn't be passing SVG elements to them in the first place. I'll look at this a bit.

I think we can just ignore delegated events if the target is SVG and don't even do the bubbling; we'd still allow them on directly bound events as we always have. Since the matcher needs .getAttribute() we can use that as our marker; for oldIE's sake we have to use typeof. The only other place where I know we don't have .getAttribute() is that #12945 bug with Flash in IE9, and if Flash objects start bubbling DOM events out of their guts I don't want to live in this world anymore. That just adds one more condition to the "are there delegated events" check.

if ( delegateCount && typeof event.target.getAttribute !== "undefined" &&
    !(event.button && event.type === "click") ) {

Why not !event.target.nodeType? The interface is really restricted. Although now that I think about it, it might be possible to bubble ''up'' into an SVGElementInstance, which would necessitate dealing with them in the loop.

Upon further inspection, it appears that SVGElementInstances are never the parentNodes of anything else, which makes our task easier. As for the fix, we can either black-hole events inside of SVG <use> elements or jump into the real DOM with correspondingUseElement. The former seems unfairly harsh, but the latter a bit dirty.

In either case, it would be nice to abstract out delegate matching logic into another jQuery.event method so it can potentially be overridden by people who have strong opinions about the way we've addressed the issues.

https://github.com/jquery/jquery/pull/1130

Fix #13180: don't delegate into SVG <use>

Changeset: f860e0bd2f7dd228a14704d78ed5208cbe870d01

Fix #13180: don't delegate into SVG <use>

(cherry picked from commits 36457cb6afc12d4a755cf93442a502783a669517..f860e0bd2f7dd228a14704d78ed5208cbe870d01)

Changeset: b75b9ef8d030b0dbf247e826bfbf9585c7dbf98b