Closed Bug 12268 Opened 21 years ago Closed 21 years ago

area frame not returning correct max element size upon 2nd unconstrained reflow

Categories

(Core :: Layout, defect, P3, minor)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: karnaze, Assigned: buster)

References

()

Details

In the following, the cell Reflows its area frame unconstrained, but the max
element width is too small causing the table to be too narrow. I've included
part of the stack.

<table border>
 <tr>
  <td><img src=do_not_find width=600 height=100></td>
</tr>
</table>

nsTableCellFrame::Reflow(nsTableCellFrame * const 0x0223bf14, nsIPresContext &
{...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned
int & 0) line 592
nsContainerFrame::ReflowChild(nsIFrame * 0x0223bf10, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 439 + 28 bytes
nsTableRowFrame::IR_TargetIsChild(nsTableRowFrame * const 0x02238d30,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, RowReflowState & {...},
unsigned int & 0, nsIFrame * 0x0223bf10) line 1301 + 34 bytes
Kipp, I think the table code may have been previously covering up this bug by
failing to reinitialize the column widths during the 2nd pass 1 reflow. My next
checkin will properly reinitialize the widths and fix bug 625. So, I think this
bug may cause a flood of others to be submitted. It appears that anytime an
image is not found and specifies a width, the table may be horked.
Status: NEW → ASSIGNED
Target Milestone: M17
Severity: normal → minor
Target Milestone: M17 → M11
Target Milestone: M11 → M14
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
With the current codebase, it works for me...
Status: RESOLVED → VERIFIED
With the Oct 1 build, the table appears correct.
You need to log in before you can comment on or make changes to this bug.