174688 - top border padding gets applied to block level next-in-flows

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect, P3)

Description

[karnaze (gone)]

Kin discovered in bug 127145 that blocks/inlines do not consider whether a child
block level frame has a prev-in-flow when positioning the child using the top
border padding of the child (i.e. the top border padding is always used). There
are several places where this needs to be changed. It is unclear which places in
nsHTMLReflowState need to be changed, because if a change causes the computed
height for a next-in-flow to differ from the first-in-flow, some frame classes
are going to break (besides, if the computed height for a next-in-flow were to
differ it should differ in other ways than just the top border padding which is
getting a bit beyond the scope of what nsHTMLReflowState should be doing).

Comment 1

[karnaze (gone)]

Attachment: printing test case from bug 127145

Comment 2

[karnaze (gone)]

Attachment: printing test case from bug 127145

Its a shame I have to use IE to attach this file as html (m1.0 branch attaches
it as a gif).

Comment 3

[Christian Reis]

Comment on attachment 103022 [details]
printing test case from bug 127145

yep, though you can change the mime type in the "edit attachment" page in
bugzilla.

Comment 4

[Kevin McCluskey (gone)]

Bulk setting karnaze's P2-P5 bugs to future

Comment 5

[karnaze (gone)]

mass reassign to default owner

Comment 6

[Bernd]

this is a block issue the testcase does not use tables

Comment 7

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

Attachment: fix

While working on bug 288560 I came up with a fix to this bug (174688). The fix
turned out to be unnecessary for 288560 but we might as well have it anyway.
The idea is just to have nsBlockReflowState::BorderPadding() compute the
borderpadding taking into account that continuations don't have top
borderpadding; nsHTMLReflowState::mComputedBorderPadding continues to have the
style borderpadding. I'm also changing the way non-auto-height blocks compute
their frame height to be more sane. In particular we need to ensure that if
such a frame is incomplete, it always grows to fill the available height,
otherwise we get funny looking gaps in the left/right borders at the bottom of
each column.

Comment 8

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

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

r+sr=dbaron.  (Are there any problems with bottom border/padding?)

Comment 9

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

The bottom border and padding are OK; when we detect that the block is
incomplete, we already don't add them.

Comment 10

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

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

This is a fix for printing and columns to make borders look better for
non-auto-height elements. It's very clearly only going to affect printing and
columns.

Comment 11

[Asa Dotzler [:asa]]

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

a=asa

Comment 12

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

checked in