Bug 14167 – event listeners on <use> elements wrongly return evt.target as an SVGElementInstance

• Status: RESOLVED
• Resolution: INVALID
• Component: SVG

[Jean-Pierre Fiset]

When a <use> element is accessed via javascript, its ownerDocument attribute is found undefined.

[Jean-Pierre Fiset]

Created attachment 15054 [details]
Test Case

[Jean-Pierre Fiset]

This is probably related to Bug 14170. It appears that there is no DOM access from the javascript bindings when it comes to a <use> element.

[Eric Seidel (no email)]

You're correct, this is a bug.  We're incorrectly returning an SVGElementInstance, even though the listeners were set on the <use> itself, and not on the referenced content.  It would be interesting to see a test which also set the listeners on the <rect>.  I think we'd then show the proper behavior (returning an SVGElementInstance, which does not actually expose any ownerDocument interface).

[Jean-Pierre Fiset]

Eric, this is a good question. If the mouse events were set on the <rect> definition as opposed to the <use> element (I must admit, I had never considered this possibility), what would the event target be?

I always assumed that the event target would be the rendered element (in this case, the <use> element), but I am not sure if I am right.

Another case would be if the mouse events were set on a parent <g> element. During bubbling up, the event would be sent to the parent's event handler, but the event target would remain the rendered element (the <use> element). Or, at least, that is my interpretation of the situation.

What do you think the proper behaviour should be?

[Jean-Pierre Fiset]

Re-reading the specs, I now understand better your comment, Eric. Thanks for the clarification.

http://www.w3.org/TR/SVG/struct.html#UseElement

"The effect of a 'use'  element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use'  element's ancestors as its higher-level ancestors."

The "deep cloning" aspect leads me to believe that the ownerDocument attribute should be set to the receiving document.

Also, on the related bug 14170, a cloned node should be able to support DOM methods, such as getAttribute().

[Jean-Pierre Fiset]

Thanks so much for the help. Yes, Safari is specs compliant.