Bug 14167 - event listeners on <use> elements wrongly return evt.target as an SVGElementInstance
: event listeners on <use> elements wrongly return evt.target as an SVGElementI...
: WebKit
: 523.x (Safari 3)
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To:
  Show dependency treegraph
Reported: 2007-06-15 07:41 PST by
Modified: 2007-06-20 07:07 PST (History)

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


You need to log in before you can comment on or make changes to this bug.

Description From 2007-06-15 07:41:29 PST
When a <use> element is accessed via javascript, its ownerDocument attribute is found undefined.
------- Comment #1 From 2007-06-15 07:42:36 PST -------
Created an attachment (id=15054) [details]
Test Case
------- Comment #2 From 2007-06-15 10:36:05 PST -------
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 From 2007-06-15 10:37:29 PST -------
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 From 2007-06-15 10:50:01 PST -------
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 From 2007-06-15 13:27:45 PST -------
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 From 2007-06-20 07:07:43 PST -------
Thanks so much for the help. Yes, Safari is specs compliant.