266772 - Possible issues in XTF frame construction

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

As a preamble, I don't quite know what XTF frame construction is aiming to
achieve.  So I'm not sure how many of the following issues are by-design....  We
probably want to file bugs for the ones that are actually bugs and track them
here.  In what follows, I'm assuming that given that nsXTFXMLBlockDisplayFrame
is an nsBlockFrame and that nsXTFXMLInlineDisplayFrame is an nsInlineFrame one
would expect them to behave as blocks or inlines.

So the issues I see in ConstructXTFFrame are:

1)  XTF frames with display values of table, table-row, table-cell,
    table-row-group, table-column-group, list-item, etc, etc are all being
    treated as inlines.

2)  Columns are not supported on XTF block frames.

3)  Overflow is not supported on XTF frames.

4)  Positioned XTF frames do not become containing blocks for absolutely
    positioned descendants.

5)  Block XTF frames do not become containing blocks for floated descendants.

6)  Inline XTF frames do not handle block descendants (causing bug 266685,
    probably).

7)  AppendFrames is used on the insertionFrame, which generates an extra reflow
    command... I suspect this could just use setInitialChildList, but I could be
    wrong.

8)  Absolutely positioned XTF blocks don't become margin roots (see
    NS_NewAbsoluteItemWrapperFrame, eg).

9)  Floated XTF blocks don't shrink-wrap (see NS_NewFloatingItemWrapperFrame).

For a lot of these issues, the right fix is to simply use
ConstructBlock/ConstructInline, which may need to be modified accordingly.  With
some factoring of code out of ConstructFrameByDisplayType(), this may fix issues
2, 3, 4, 5, 6, 8, 9.  For the rest, I'm not sure what the best way to proceed is.

Comment 1

[Alex Fritze]

(In reply to comment #0)
> As a preamble, I don't quite know what XTF frame construction is aiming to
> achieve.  So I'm not sure how many of the following issues are by-design....  

You can assume that most stuff that doesn't look quite right is not by design,
but a result of my general ignorance of frame construction issues. I've only
really used XTF in a XUL & SVG setting.

> 1)  XTF frames with display values of table, table-row, table-cell,
>     table-row-group, table-column-group, list-item, etc, etc are all being
>     treated as inlines.

I guess when demand for these display types arises we should rethink our
layout-side xtf implementation strategy. Deriving new frame classes for all
possible display types seems a bit excessive. We only subclass frame classes to
add nsIAnonymousContentCreator and for 'DidLayout()' calls. 
If we add a flag to nsIFrame for marking frames as being 'xtf' frames, we could
change the code in nsCSSFrameCTOR::CreateAnonymousFrames() to QI xtf content
elements for nsIAnonymousContentCreator (rather then their frames).

> 7)  AppendFrames is used on the insertionFrame, which generates an extra reflow
>     command... I suspect this could just use setInitialChildList, but I could be
>     wrong.

Hmm, wouldn't that mean that 'setInitialChildList' might get called twice on the
insertionFrame?
 

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Hmm, wouldn't that mean that 'setInitialChildList' might get called twice on
> the insertionFrame?

Hmm... if the insertionFrame can have anonymous kids, then yes.  So never mind that.

Comment 3

[Boris Zbarsky [:bzbarsky]]

One other possible issue, or at least annoyance in what I'm working on now... is
there a reason to code the xtfElem->GetElementType() ==
nsIXTFElement::ELEMENT_TYPE_GENERIC_ELEMENT check into frame construction
instead of putting it in style resolution or something along those lines and
just having it force display:none?  At the moment this is at least making us
resolve visibility structs for those elements unnecessarily, quite apart from
complicating other code that has to work around the fact that these frames
suddenly decide to not be there (see XXX comments I'll add in bug 269566).

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

XTF visuals have been removed (Bug 355100), so this is WFM.