Closed
Bug 826858
Opened 11 years ago
Closed 11 years ago
Figure out which classes should derive from DOMSVGTests
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
FIXED
People
(Reporter: dzbarsky, Assigned: dzbarsky)
Details
SVGGraphicsElement is supposed to implement SVGTests, but FilterElement should not (and nsSVGFilterElement derives from SVGGraphicsElement in our implementation).
Comment 1•11 years ago
|
||
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?
Assignee | ||
Comment 2•11 years ago
|
||
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.
Comment 3•11 years ago
|
||
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.)
Comment 4•11 years ago
|
||
See bug 825411 for a testcase where we go wrong.
Assignee | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•