Closed Bug 367458 Opened 13 years ago Closed 13 years ago

remove nsTableFrame::GetBorderPadding

Categories

(Core :: Layout: Tables, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: dbaron)

References

Details

(Whiteboard: [patch])

Attachments

(1 file)

Both versions of nsTableFrame::GetBorderPadding should be able to go away now that we have better APIs (one's a little tricky, but still doable).
Actually, though, I think the one that's a little tricky should be able to go away entirely, since it's in code that was intended for unconstrained reflow (although it's actually checking NS_FRAME_FIRST_REFLOW).
OS: Linux → All
Hardware: PC → All
Whiteboard: [patch]
Attached patch patchSplinter Review
So there was one use of each version of GetBorderPadding:

* The use in CalcAvailWidth would have been the trickier to replace (although it was only a few lines, constructing an nsCSSOffsetState).  However, I claim that I should have removed that whole part of the function during the reflow branch; anything that's supposed to happen only for the initial reflow is inherently broken, and in the case of table cells, what was then the initial reflow was always for intrinsic width determination.

* The use in VerticallyAlignChild is after the frame has been reflowed, so GetUsedBorderAndPadding is what we want to replace it with.  (Note that nsBCTableCellFrame overrides GetUsedBorder.)

The rest of the patch is just the resulting code removal and parameter removal.

reftests pass
Attachment #252667 - Flags: superreview?(roc)
Attachment #252667 - Flags: review?(bernd_mozilla)
Attachment #252667 - Flags: superreview?(roc) → superreview+
Attachment #252667 - Flags: review?(bernd_mozilla) → review+
Checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.