Closed Bug 316057 Opened 19 years ago Closed 17 years ago

intrinsic height float or absolute pos elt sized around float is too tall by border-top-width

Categories

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

Product:
Core
Component:
Layout: Block and Inline
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: aiaiadi, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

simpler testcase
620 bytes, application/xhtml+xml; charset=UTF-8
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
<title>border-top-width</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">

body {
	background-color:#ccc;
}

#block1 {
	position:absolute;
	background-color:red;
	border:5px solid #fff;
	border-width:10px 3px 3px 3px;
}

#block2 {
	width:200px;
	position:absolute;
	top:100px;
	background-color:red;
	border:5px solid #fff;
	border-width:10px 3px 3px 3px;
}

#block3 {
	width:200px;
	position:absolute;
	top:200px;
	background-color:red;
	border:5px solid #fff;
	border-width:0px 3px 3px 3px;
}

#block4 {
	top:300px;
	position:absolute;
	background-color:red;
	border:5px solid #fff;
	border-width:10px 3px 3px 3px;
}

ul {
	list-style-type:none;
	padding:0;
	margin:0;
}

li {
	float:left;
	display:block;
	background-color:green;
	height:2em;
	line-height:2em;
}

p {
	float:left;
	display:block;
	background-color:green;
	height:2em;
	line-height:2em;
	margin:0;
	padding:0;
}


</style>
</head>
<body>

<div id="block1">
<ul>
<li>aaaa</li>
<li>aaaa</li>
<li>aaaa</li>
</ul>
</div>

<div id="block2">
<ul>
<li>aaaa</li>
<li>aaaa</li>
<li>aaaa</li>
</ul>
</div>

<div id="block3">
<ul>
<li>aaaa</li>
<li>aaaa</li>
<li>aaaa</li>
</ul>
</div>

<div id="block4">
<p>aaaa</p>
<p>aaaa</p>
<p>aaaa</p>
</div>


</body>
</html>

Reproducible: Always

Steps to Reproduce:
1. block1 shows wrong behavior
2. block2 including width
3. block3 without border-top
4. block4 using alternative block element


change border-width / border-top-width of block1



Expected Results:  
border-top-width must not influence bottom padding of parent-block element

This was tested using following browsers:
- Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
- Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
- Camino OSX Version 2004120113 (0.8.2)
(In reply to comment #0)
> <?xml version="1.0" encoding="iso-8859-1"?>

Please don't paste testcases into bugs; create attachments instead.

> 1. block1 shows wrong behavior

The reason we ask for "Steps to reproduce", "Actual results", and "Expected results" separately is so that we don't get general statements like "wrong behavior".  What those parts ask you to do is describe what's wrong about the behavior, by separately describing (1) what behavior to look at (2) what it is and (3) what it should be.
Steps to reproduce:
 1. load attachment 202707 [details]
 2. look at the first block

Actual results: the first block has red background showing through at the bottom edge

Expected results:  there should be no red on the first block (although there should be on the side of the second and third)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: strange behavior of border-top-width property using nested div and ul/li block elements. occurs if width of parent block element is not set → intrinsic height float or absolute pos elt sized around float is too tall by border-top-width
So there's a lot of messy space manager translation code, but it all looks right now that I spent 20 minutes understanding it (so I still don't see the problem):

 * When nsIFrame::Reflow is called, the space manager is expected to be in frame coordinates (i.e., translated to the reflowed frame's border edge)
 * nsBlockReflowState's constructor and destructor ensure that space managers have the translation relative to the content edge while reflowing a block.  This is generally true, except in nsBlockReflowState::RecoverFloats, where it's always relative to the border edge (since that's what the float cache has)
 * nsBlockReflowContext::ReflowBlock and nsLineLayout::ReflowFrame undo the special block translation before reflowing a child.  (I'm not convinced that the way line layout does this makes sense, though.)
 * space manager's XMost and YMost deal with untranslated coordinates, which for blocks that have a space manager, are relative to the block's border edge, since block reflow state's constructor / destructor translation happens even for a space manager for the block itself
It looks like the reflow branch landing fixed this.
Status: NEW → RESOLVED
Closed: 17 years ago
Depends on: reflow-refactor
Flags: in-testsuite?
Resolution: --- → FIXED
Checked in reftest for this.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: