280988 - SVG frames should implement GetFrameName

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Boris Zbarsky [:bzbarsky]]

See nsIFrameDebug.h.

Implementing GetFrameName will have two main benefits benefits:

1)  Better accuracy of the regression tests if those start including SVG
2)  More useful output from Dump Frames in the layout debugger.

Note that the method should be both declared and implemented inside #ifdef DEBUG.

Comment 1

[Scooter Morris]

Attachment: Adds GetFrameName and GetType to all SVG Frames

Comment 2

[Boris Zbarsky [:bzbarsky]]

So... with foreignobject you have to be a little careful.  You might want to
leave the type as-is until you've audited all existing places where the
blockFrame and areaFrame types are tested for (chances are that any place that
tests for both needs to test for foreignObject too....)

Alternately, you could just leave foreignObject claiming to be a block as far as
type goes, and audit code that checks display types to make sure it deals with
foreign objects that have display:inline on them.

Comment 3

[Scooter Morris]

(In reply to comment #2)
> So... with foreignobject you have to be a little careful.  You might want to
> leave the type as-is until you've audited all existing places where the
> blockFrame and areaFrame types are tested for (chances are that any place that
> tests for both needs to test for foreignObject too....)

If I take this approach, its going to mean adding #ifdef MOZ_SVG code into
several files in layout/generic and possibly tables/nsTableFrame.cpp.  I think
I'll resubmit the patch without GetType for foreignObject and handle that
separately.

> 
> Alternately, you could just leave foreignObject claiming to be a block as far as
> type goes, and audit code that checks display types to make sure it deals with
> foreign objects that have display:inline on them.

That looks like it touches a hole bunch more files.  If the first approach is
workable, it certainly seems like it would involve less.

Comment 4

[Scooter Morris]

Attachment: Removed GetType from foreignObject

OK, here is an update that does not implement GetType for foreignObject until
we can make the other changes necessary -- perhaps wrapping it in with other
fixes to the foreignObject implementation.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I think I'll resubmit the patch without GetType for foreignObject and handle
> that separately.

Yeah, definitely.

> If the first approach is workable

It's somewhat workable... Probably still need to audit code to see what things
are being cast to and where...

Comment 6

[tor]

Checked in for Scooter.