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

RESOLVED FIXED in Future

Status

()

Core
Layout: Block and Inline
P3
normal
RESOLVED FIXED
15 years ago
12 years ago

People

(Reporter: karnaze (gone), Assigned: roc)

Tracking

({testcase})

Trunk
Future
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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).
(Reporter)

Comment 1

15 years ago
Created attachment 103022 [details]
printing test case from bug 127145
(Reporter)

Comment 2

15 years ago
Created attachment 103023 [details]
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).
Attachment #103022 - Attachment is obsolete: true

Updated

15 years ago
Attachment #103022 - Attachment mime type: image/gif → text/html

Comment 3

15 years ago
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.

Updated

15 years ago
QA Contact: petersen → amar

Updated

15 years ago
Keywords: testcase
Priority: -- → P3
Bulk setting karnaze's P2-P5 bugs to future
Target Milestone: --- → Future
(Reporter)

Comment 5

14 years ago
mass reassign to default owner
Assignee: karnaze → table
Component: Layout → Layout: Tables
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

14 years ago
Target Milestone: --- → Future

Comment 6

13 years ago
this is a block issue the testcase does not use tables
Assignee: core.layout.tables → nobody
Component: Layout: Tables → Layout: Block and Inline
QA Contact: madhur → core.layout.block-and-inline
Created attachment 180008 [details] [diff] [review]
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.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #180008 - Flags: superreview?(dbaron)
Attachment #180008 - Flags: review?(dbaron)
Comment on attachment 180008 [details] [diff] [review]
fix

r+sr=dbaron.  (Are there any problems with bottom border/padding?)
Attachment #180008 - Flags: superreview?(dbaron)
Attachment #180008 - Flags: superreview+
Attachment #180008 - Flags: review?(dbaron)
Attachment #180008 - Flags: review+
The bottom border and padding are OK; when we detect that the block is
incomplete, we already don't add them.
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.
Attachment #180008 - Flags: approval1.8b2?

Comment 11

12 years ago
Comment on attachment 180008 [details] [diff] [review]
fix

a=asa
Attachment #180008 - Flags: approval1.8b2? → approval1.8b2+
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.