320724 - document.getElementById in SVG document (image/svg+xml) fails to find SVG a hyperlink element

Status: VERIFIED DUPLICATE of bug 267664

(Core :: SVG, defect)

Description

[Martin Honnen]

In the Mozilla SVG newsgroup there was a complaint
<http://groups.google.com/group/netscape.public.mozilla.svg/browse_frm/thread/f1654ebeb35d6459/c2b7ae2bbb4473cb?hl=en#c2b7ae2bbb4473cb>
that document.getElementById in an SVG document fails to find an SVG a hyperlink element in the document.
The test case at
<http://home.arcor.de/martin.honnen/mozillaBugs/SVG/getElementById1.svg>
demonstrates that Firefox 1.5 (tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5) indeed fails to find the element.

I file this on the SVG component as I don't know how far SVG (re)uses the existing Core/XML DOM for stuff like this.

Comment 1

[Martin Honnen]

I am now testing with a Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051218 Firefox/1.6a1) and getElementById fails here too to find the SVG a element. Changing version to trunk therefore.

Comment 2

[Martin Honnen]

Current workaround to find the a element by its id could be accessing all a elements in the SVG namespace and then indexing that collection by the element id:
  var aElement = document.getElementsByTagNameNS('http://www.w3.org/2000/svg', 'a')['a1'];
That works in the test case in Firefox 1.5 and in Opera 9.0 Preview 1.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So for <svg:a> we don't actually create an nsSVGElement.  See the NS_NewSVGElement function in nsSVGElementFactory.cpp.  And nsXMLElement doesn't know that "id" attributes are IDs.

Is there a reason we're not just creating an nsSVGElement here?

Comment 4

[Darin Fisher]

Not going to block 1.8.1 for this, but we'll happily consider a baked-on-trunk patch.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #3)
> Is there a reason we're not just creating an nsSVGElement here?
> 

nsSVGElement doesn't inherit nsXMLElement.
But I don't know whether <svg:a> should inherit both
nsSVGElement and nsXMLElement.
Or would it be better to move xlink functionality to nsGenericElement 
and then <a:svg> could be just nsSVGElement.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Or would it be better to move xlink functionality to nsGenericElement 

Yes.  We have bugs on that, in fact, with partial patches.  See bug 211916.

The work was put on hold because as far as we can tell generic XLink and SVG are in fact incompatible; the response from the XLink working group to my mail on the subject was singularly unhelpful (and took about 6 months to get, so I'm not holding my breath on their answer to my followup).

We should probably remove generic XLink support if we're going to keep SVG support....

Comment 7

[Jonathan Watt [:jwatt]]

This would all be fixed I think if I'd managed to get third review on bug 334587. I had a bunch of follow up fixes I intended to land after that that would have fixed all SVG link issues I was aware of. Unfortunately the patch there is most likely completely rotted, but I haven't looked at it in a while.

Comment 8

[Jonathan Watt [:jwatt]]

Okay, bug 334587 is fixed now and the remainder of the fixes are covered by my work in bug 267664. Marking as a duplicate.

Comment 9

[Boris Zbarsky [:bzbarsky]]

For what it's worth, it's better to treat that relationship via dependencies...

In any case, we still need these testcases added to the test suite.

Comment 10

[jonathan chetwynd]

might be best to check with Martin..
the fonts really look ugly just now...

Comment 11

[Jonathan Watt [:jwatt]]

Attachment: testcase

Comment 12

[Jonathan Watt [:jwatt]]

Added reftest:
http://lxr.mozilla.org/seamonkey/source/layout/reftests/svg/getElementById-a-element-01.svg