Closed
Bug 293104
Opened 19 years ago
Closed 18 years ago
nsSVGStopFrame is an nsContainerFrame?
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 328137
People
(Reporter: bzbarsky, Unassigned)
References
Details
It looks like nsSVGStopFrame inherits from nsContainerFrame but we try (poorly) to not construct child frames for it. Is there a reason it's inheriting from nsContainerFrame? Or is that just oversight? Based on the frame impl, I think inheriting from nsFrame would make more sense... Note that I'm going to assume this frame was meant to have kids for the time being (for bug 265367)...
Comment 1•19 years ago
|
||
I would definitely put it in the oversight/lack of knowledge category. I'll check with the spec again to make sure that <stop> can't have any children (I don't think it can).
Comment 2•19 years ago
|
||
<stop> *can* have content children. In particular it is possible to add an <animate>. What is not clear is if the <animate> content child will result in a child frame -- probably (almost certainly?) not. There is discussion about the animation design going on right now. Hopefully when the approach becomes clear we can clean up the frame hierarchy.
Comment 3•19 years ago
|
||
bz, can this bug lead to crashes like the one bug 265367 caused? If so, it should be treated as a security hole.
Reporter | ||
Comment 4•19 years ago
|
||
> bz, can this bug lead to crashes like the one bug 265367 caused?
Probably not, since we're at least being consistent -- it _can_ have kids, and
we allow it to have kids.
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.9a1+
*** This bug has been marked as a duplicate of 328137 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•