Closed Bug 2062 Opened 26 years ago Closed 25 years ago

relatively positioned boxes are clipped when overflow is visible

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: troy)

References

(
URL
)

Details

relatively positioned boxes are clipped when overflow is visible.

(Also on this test, you should either do absolute positioning or completely
ignore it.  I'm not sure what's going on now.)
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
*** Bug 2422 has been marked as a duplicate of this bug. ***
Extracted from 2422:

Here's some HTML that demonstrates the problem.

<body>
<div style="position:absolute; left:20px; top:20px; width:200px; border:solid
2px red; background-color:lightyellow">
Some text in a absolutely positoned DIV tag so we can test absolute positioning
of nested_
<div style="position:absolute; left:-20px; top:-20px; width:200px; border:solid
2px blue; background-color:white">
This is the text of the nested DIV element that's also absolutely
positioned</div>absolutely positioned DIV elements</div></body>
QA Contact: 4144 → 4110
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This was fixed recently.
Status: RESOLVED → VERIFIED
Using 4/2 build, verified that positioned boxes overflow for div.contain boxes.
Verified cross platform on Win 95, Win NT, Win 98, Mac8.5 and Linux.
Status: VERIFIED → REOPENED
Using the 3/30 build, I'm only seeing the overflow on P.eight.  In P.seven, the
text should also overflow (but not the yellow) rather than be cut off.  So it
only seems to work if it's a child that overflows, not any descendant.

Also, there should also be overflow in the second, fifth, and seventh test
paragraphs, so verification of this bug should await fixing the regression
described in bug 4519.

Reopening bug.  However, if the issues described were fixed between 3/30 and 4/2
(although Kipp marked the bug fixed on 3/29), feel free to resolve it again.
Status: REOPENED → ASSIGNED
Resolution: FIXED → ---
The latest problem in bug 2502 is a duplicate of this one.  Check that out too
if you think this is fixed.  (It may still have *other* problems, visible only
once this is fixed, so I'm not resolving as duplicate.)
The text being cut off in P.seven is strange.  If I use PgDn to see it, I see
the whole line of text that is partly in the box (but not the ones below it).
If I scroll, the text is cut off at a line at or just below the bottom of the
box.  That line, I think, is the bottom of where the page was when the window
was refreshed for the first time with the bottom of the box above the top of
the page.
Text is also being clipped in the upper left box in the second test in

http://www.fas.harvard.edu/~dbaron/csstest/sec1001c
There seems to be one bug left; the p.eight paragraph is being clipped;
everything else is working fine.
Assignee: kipp → troy
Status: ASSIGNED → NEW
The test labeled "p.eight" doesn't get its size set right during the setup of
the html reflow state. Here is a debug printout from
nsAbsoluteContainingBlock.cpp:

Area(p)(1)@0x819eb18: availSize=5745,1073741824 computed=5145,1290
desired=5145,1290

The block code is well trained to honor a computed-height and consequently
returns that height. The question is - why is the computed-height set at all!
The parent of p.eight is a div which has a fixed height, yet p.eight has no
specified height...

The InitAbsoluteConstraints code in nsHTMLReflowState is doing this, and since I
don't know why I'm giving this to troy to fix...
Even if this is due to a sizing bug with the P.eight (which seems reasonable),
you still have a clipping problem, since inline boxes can (and should, by
default) overflow out of their parent block box.  There may be another bug on
that...
Actually the height of p.eight itself is set by the positioning and should not
depend on its content.  Following the steps to compute heights, margins, and
offsets in http://www.w3.org/TR/REC-CSS2/visudet.html#abs-non-replaced-height :

1. nothing happens
2. bottom is set to 0, since height is auto
3. nothing happens
4. nothing happens
5. there is one auto left, height.  Thus height= containing block height -
top.  This is the computed value that should be returned for height.
6. ignored

Absolutely positioned elements are never sized based on the size of their
children.  (They could be sized based on their containing block's other
children, but that's a bit different.)

Thus I think this is a clipping bug.  Or am I missing something?
Blocks: 2502
Once this bug is fixed, reexamine bug 2502.
Target Milestone: M15
Removing Kipp's M15 marker, since this bug is important.
Status: NEW → ASSIGNED
David's right it's a clipping problem.
It's definitely a clipping problem. You can tell by where the yellow background
is painting: that represents the actual size of P.eight and the text should be
clipped to there as well.
What I meant to say is that the text should not be clipped
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Verified fixed, on all test pages mentioned.
You need to log in before you can comment on or make changes to this bug.