Closed
Bug 174688
Opened 22 years ago
Closed 19 years ago
top border padding gets applied to block level next-in-flows
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: karnaze, Assigned: roc)
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
528 bytes,
text/html
|
Details | |
10.40 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
asa
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
Reporter | ||
Comment 2•22 years ago
|
||
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•22 years ago
|
Attachment #103022 -
Attachment mime type: image/gif → text/html
Comment 3•22 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•22 years ago
|
QA Contact: petersen → amar
Reporter | ||
Comment 5•21 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
Component: Layout → Layout: Tables
QA Contact: amar → madhur
Target Milestone: Future → ---
Updated•21 years ago
|
Target Milestone: --- → Future
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
Assignee | ||
Comment 7•19 years ago
|
||
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+
Assignee | ||
Comment 9•19 years ago
|
||
The bottom border and padding are OK; when we detect that the block is incomplete, we already don't add them.
Assignee | ||
Comment 10•19 years ago
|
||
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•19 years ago
|
||
Comment on attachment 180008 [details] [diff] [review] fix a=asa
Attachment #180008 -
Flags: approval1.8b2? → approval1.8b2+
Assignee | ||
Comment 12•19 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•