Closed Bug 293104 Opened 19 years ago Closed 18 years ago

nsSVGStopFrame is an nsContainerFrame?

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
normal

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)...
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).
<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.
bz, can this bug lead to crashes like the one bug 265367 caused?  If so, it
should be treated as a security hole.
> 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.
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.