Closed
Bug 344894
Opened 19 years ago
Closed 18 years ago
abs.pos. child of <legend> is not rendered
Categories
(Core :: Layout: Positioned, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: MatsPalmgren_bugz, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•19 years ago
|
||
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•19 years ago
|
||
So this seems to sorta work on reflow branch, I think... Not sure why.
Flags: blocking1.9a2?
Assignee | ||
Comment 3•19 years ago
|
||
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.
Assignee | ||
Comment 4•19 years ago
|
||
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.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #229924 -
Flags: superreview?(dbaron)
Attachment #229924 -
Flags: review?(dbaron)
Flags: blocking1.9a2? → blocking1.9-
Whiteboard: [wanted-1.9]
Reporter | ||
Comment 5•18 years ago
|
||
FWIW, the bug still occurs after the reflow branch landing.
The attached patch still fixes it.
Comment 6•18 years ago
|
||
Comment on attachment 229924 [details] [diff] [review]
fix
r+sr=dbaron. Sorry for the delay.
Attachment #229924 -
Flags: superreview?(dbaron)
Attachment #229924 -
Flags: superreview+
Attachment #229924 -
Flags: review?(dbaron)
Attachment #229924 -
Flags: review+
Assignee | ||
Comment 7•18 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: in-testsuite?
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•