344894 - abs.pos. child of <legend> is not rendered

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Mats Palmgren (inactive)]

abs.pos. child of <legend> is not rendered. (URL is testcase from bug 310879)

This is a trunk regression: 2006-01-25-05  --  2006-01-26-04
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-25+03%3A00&maxdate=2006-01-26+06%3A00&cvsroot=%2Fcvsroot

Most likely in that range: bug 317375

Comment 1

[Mats Palmgren (inactive)]

Attachment: Frame dump

This is the frame tree from trunk. I also dumped from 1.8 branch (where the
testcase works) and the frame trees are identical AFAICT.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So this seems to sorta work on reflow branch, I think...  Not sure why.

Comment 3

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

Okay ... the problem here is that the placeholder is inside the <legend> frame, but the abs-pos frame is a child of the fieldset's anonymous block frame, which violates the invariant that the placeholder is a descendant of the out-of-flow frame's parent. We need to do BuildDisplayList on the abs-pos container before we reach the placeholder, because that needs to set up the abs-pos frames to be painted later through the placeholders. In this case we're seeing the placeholder before we've visited the abs-pos container so the abs-pos frame doesn't get painted.

Comment 4

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

Attachment: fix

fairly straightforward approach ... just process mContentFrame before mLegendFrame, because mContentFrame might have out-of-flow frames whose placeholders are under mLegendFrame, but the other way around is not possible. The patch ensures that we still keep content in the same z-order.

Hmm, actually we might currently have a bug where the legend should be z-ordered according to where it is in the content relative to other children of the fieldset. But at least this patch preserves current z-ordering.

Comment 5

[Mats Palmgren (inactive)]

FWIW, the bug still occurs after the reflow branch landing.
The attached patch still fixes it.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 229924 [details] [diff] [review]
fix

r+sr=dbaron.  Sorry for the delay.

Comment 7

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

checked in