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: 26 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.
Also, the text is also cut off in P.eight in http://www.fas.harvard.edu/~dbaron/csstest/sec090302c
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: 26 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.