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.
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.
Version: 1.8 Branch → Trunk
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.
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?
Not going to block 1.8.1 for this, but we'll happily consider a baked-on-trunk patch.
Flags: blocking1.8.1? → blocking1.8.1-
(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.
> 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....
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.
Okay, bug 334587 is fixed now and the remainder of the fixes are covered by my work in bug 267664. Marking as a duplicate.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 267664
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.
Flags: blocking1.9? → in-testsuite?
might be best to check with Martin.. the fonts really look ugly just now...
Status: RESOLVED → VERIFIED
Added reftest: http://lxr.mozilla.org/seamonkey/source/layout/reftests/svg/getElementById-a-element-01.svg
Flags: in-testsuite? → in-testsuite+
OS: Windows XP → All
Hardware: PC → All
You need to log in before you can comment on or make changes to this bug.