Bug 14167 - event listeners on <use> elements wrongly return evt.target as an SVGElementInstance
Summary: event listeners on <use> elements wrongly return evt.target as an SVGElementI...
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2007-06-15 07:41 PDT by Jean-Pierre Fiset
Modified: 2007-06-20 07:07 PDT (History)
2 users (show)

See Also:

Test Case (2.45 KB, image/svg+xml)
2007-06-15 07:42 PDT, Jean-Pierre Fiset
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Pierre Fiset 2007-06-15 07:41:29 PDT
When a <use> element is accessed via javascript, its ownerDocument attribute is found undefined.
Comment 1 Jean-Pierre Fiset 2007-06-15 07:42:36 PDT
Created attachment 15054 [details]
Test Case
Comment 2 Jean-Pierre Fiset 2007-06-15 10:36:05 PDT
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.
Comment 3 Eric Seidel 2007-06-15 10:37:29 PDT
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).
Comment 4 Jean-Pierre Fiset 2007-06-15 10:50:01 PDT
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?
Comment 5 Jean-Pierre Fiset 2007-06-15 13:27:45 PDT
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().
Comment 6 Jean-Pierre Fiset 2007-06-20 07:07:43 PDT
Thanks so much for the help. Yes, Safari is specs compliant.