Figure out which classes should derive from DOMSVGTests

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: dzbarsky, Assigned: dzbarsky)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

6 years ago
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?
(Assignee)

Comment 2

6 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.
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.
(Assignee)

Updated

5 years ago
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.