Boris Zbarsky [:bzbarsky] Reporter
	Description • 21 years ago

Right now, we call PushAbsoluteContainingBlock from all sorts of places in the
frame constructor.  Very few do it correctly.... Examples:

1)  Tables are never absolute containing blocks right now (never call
    PushAbsoluteContainingBlock on themselves)
2)  Fieldsets are not absolute containing blocks if they are relatively
    positioned
3)  ConstructHTMLFrame has this isPositionedContainingBlock local that it never
    sets to anything but FALSE.  Then it has some code to push a containing
    block if it's true...

I stopped reading at that point, but I was only 30% through the file....

In any case; the goal here, in my opinion, is to minimize the number of places
where PushAbsoluteContainingBlock may need to be called.  The fewer callers
there are, the less chance that one of them will get it wrong.

Thoughts?

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 1 • 21 years ago

roc, dbaron, any ideas how we can consolidate the codepaths here?

	Bernd
	Comment 2 • 19 years ago

>Tables are never absolute containing blocks right now

Should they ever be?, as soon as we hit a wrapper around a abs. pos. frame, table frames will create pseudo frames anyway. 

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 3 • 19 years ago

Tables should be absolute containing blocks when they are relatively or absolutely positioned.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 4 • 19 years ago

IMHO post-reflow-branch we need to reorganize absolute positioning so that any frame can be an abs-pos container ... nsAbsoluteContainer will have to become a property.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 5 • 19 years ago

While that's true, I think that in some cases (eg SVG, MathML) we don't necessarily want to make things into absolute containing blocks per the CSS definitions (eg. just because they are relatively positioned).

	Carlos Alén Silva
	Comment 6 • 14 years ago

Shouldn't the platform for this bug be "x86 all" or "all all"?

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 7 • 14 years ago

Sure, except those fields don't matter at all.  So setting them "right" when filing isn't worth the bother...

	(no longer active)
	Comment 8 • 13 years ago

Boris, can you please see what's left here with bug 10209 and bug 656130 being fixed?

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 9 • 13 years ago

The main issue is still there: right now it's easy to forget to push a frame class as an absolute containing block.... Then again, pushing a frame that doesn't have the magic goop to work as an absolute containing block won't help much either...

I'm not sure there's a good solution for it, necessarily, and this is low on my priority list for the moment.

	henryfhchan
	Comment 10 • 11 years ago

This should at least be fixed for td and fieldset elements (as the number of bugs this indirectly blocks), consolidating the codepath can follow later.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 11 • 11 years ago

This doesn't need to be fixed to fix the td situation.