Created attachment 15054 [details]
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).
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?
Re-reading the specs, I now understand better your comment, Eric. Thanks for the clarification.
"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().
Thanks so much for the help. Yes, Safari is specs compliant.