515530 - Merge nsHTMLContainerFrame, nsContainerFrame to one class

Status: RESOLVED FIXED

(Core :: Layout, enhancement)

Description

[Mats Palmgren (inactive)]

Followup from bug 233463 comment 62 --
From  Boris Zbarsky (:bz) 2009-08-25 08:44:30 PDT:

For that matter, I'm not quite sure why we have separate nsHTMLContainerFrame
and nsContainerFrame, but that's also fodder for a separate bug.

Comment 1

[Boris Zbarsky [:bzbarsky]]

dbaron, roc, is there a point to having these be separate classes?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't think so.

Comment 3

[Mats Palmgren (inactive)]

Attachment: fix

There was one issue - both nsHTMLContainerFrame, nsContainerFrame
implements BuildDisplayList.  Identically, except nsHTMLContainerFrame
uses DISPLAY_CHILD_INLINE and nsContainerFrame does not.

Investigating all classes that inherit nsHTMLContainerFrame...
   nsHTMLFramesetFrame
   nsInlineFrame
implements BuildDisplayList that explicitly calls nsHTMLContainerFrame::BuildDisplayList
   nsProgressFrame
   nsFirstLetterFrame
does not implement BuildDisplayList

I made the above four have a BuildDisplayList that calls a new (protected)
convenience method BuildDisplayListForInline that implements the
DISPLAY_CHILD_INLINE version.

The remaining derived classes all implements BuildDisplayList but
does not call nsHTMLContainerFrame::BuildDisplayList.

Comment 4

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7db218a91c88

Comment 5

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/7db218a91c88