SVGGraphicsElement is supposed to implement SVGTests, but FilterElement should not (and nsSVGFilterElement derives from SVGGraphicsElement in our implementation).
Is this really about the DOM API, or about internals? It's quite OK to have the FilterElement interface and all its interface ancestors not implement SVGTests, even while our concrete dom::FilterElement inherits from some internal class that does SVGTests. The concrete class would then have the methods, but they wouldn't be exposed on the JS object, since the interface doesn't have them. Or am I totally misunderstanding the problem?
The issue is that we have code QI's elements to DOMSVGTests, like https://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGElement.cpp#582 So elements should not derive from DOMSVGTests if they don't implement SVGTests.
Well. They can inherit from it as long as they don't QI to it, right? Those are also independent things... (Note: that particular QI is actually QIing to nsIDOMSVGTests and then reinterpret_casting; that happens to be OK kinda by accident, as long as you know you started with an nsINode.)
See bug 825411 for a testcase where we go wrong.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.