Closed Bug 214844 Opened 21 years ago Closed 21 years ago

[FIX] relatively positioned block w/ overflow:auto should be absolute pos. containing block

Categories

(Core :: Layout: Positioned, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: AndyStone, Assigned: MatsPalmgren_bugz)

Details

(Keywords: testcase, Whiteboard: [patch])

Attachments

(3 files, 2 obsolete files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 An absolute block should be contained by (and so positioned inside or relative to the selected corner of) the "the nearest ancestor with a 'position' other than 'static'," (see CSS2 10.1) href=http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details EXAMPLE: <head><style type='text/css'> #Block2 { display:block; position:relative; border-width:2px ;border-style:dashed; overflow:auto; width:auto; height:auto; } #Block3 { display:block;position:relative; border-width:2px ;border-style:dashed; overflow:auto; width:100%; height:100%; } #Block4 { display:block;position:absolute; border-width:2px ;border-style:dashed; overflow:auto; left:0 ; top:0 ; width:50% ; height:auto ; z-index:1 } #Block5 { display:block;position:absolute; border-width:2px ;border-style:dashed; overflow:auto; left:10 ; top:50 ; width:50% ; height:auto ; z-index:1 } </style></head><body> <div id=Block2> Use up space <br><br> </div> <div id=Block3> <br><br><br><br><br><br><br><br><br><br><br> If you change the positioning of block 3 to absolute You will see correct positioning of the children <div id=Block4> this is mispositioned so it cant be seen </div> <div id=Block5> You can see this, but it is mispositioned relative to the top left of the screen. It should be relative to the "the nearest ancestor with a 'position' other than 'static'," (see CSS2 10.1 <a href=http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details> http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details</a> </div> </div> </body> Reproducible: Always Steps to Reproduce: Just load the example in the browser Actual Results: A block that should be shown is hidden because it is outside of the dimensions of the containing block. A block that should be 50 pixels lower and 10 to the right from the top left of the containing block appears right at the top left (I chose the 50/10 so you it would appear there) Expected Results: Change block 3 to "absolute" to see what it should have done (WRT the children).
Attached file example from comment 0 (obsolete) —
This is the example given by the reporter... formatted a little with minor changes (doctype, "px" on css units, etc.) Reporter, in the future it would be helpful to postt the example on a site and point to it with the URL field or post the example as an attachment after you file the bug.
It's the overflow:auto on the DIV with ID block3 that's breaking things.
Assignee: block-and-inline → position
Component: Layout: Block & Inline → Layout: R & A Pos
Summary: absolute block inside relative block is positioned relative to screen not block → relatively positioned block w/ overflow:auto should be absolute pos. containing block
Attached file Testcase
Attachment #129058 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Bug also occurs in Mozilla 1.0.2 and 1.3.1 on Linux
Also, overflow:scroll has the same problem. All the others work.
-> All/All (OS X)
OS: Linux → All
Hardware: PC → All
The problem is that the abs.pos. child ends up on the "absolute list" for Area(html) rather than the rel.pos. parent's "absolute list". Taking this since I have a patch.
Assignee: position → mats.palmgren
Summary: relatively positioned block w/ overflow:auto should be absolute pos. containing block → [FIX] relatively positioned block w/ overflow:auto should be absolute pos. containing block
Whiteboard: [patch]
Attached patch Patch rev. 1 (obsolete) — Splinter Review
PushAbsoluteContainingBlock() when rel. pos. too
Attachment #129068 - Flags: review?(dbaron)
FYI, there is similar code in nsCSSFrameConstructor::InitializeSelectFrame and nsCSSFrameConstructor::ConstructFieldSetFrame. I did update those too but couldn't see any improvement - these frame types does not seem to handle positioned children so I excluded it from the patch.
Comment on attachment 129068 [details] [diff] [review] Patch rev. 1 r+sr=dbaron, and it's probably better to fix the other two as well in case somebody copies the code (which somebody obviously did to create those functions in the first place!)
Attachment #129068 - Flags: superreview+
Attachment #129068 - Flags: review?(dbaron)
Attachment #129068 - Flags: review+
Attached patch Patch rev. 2Splinter Review
OK, this fixes InitializeSelectFrame and ConstructFieldSetFrame too
Attachment #129068 - Attachment is obsolete: true
Attachment #129074 - Flags: review?(dbaron)
Attachment #129074 - Flags: superreview+
Attachment #129074 - Flags: review?(dbaron)
Attachment #129074 - Flags: review+
Comment on attachment 129074 [details] [diff] [review] Patch rev. 2 Could this please be approved for 1.5b? Pretty straightforward correctness fix...
Attachment #129074 - Flags: approval1.5b?
Comment on attachment 129074 [details] [diff] [review] Patch rev. 2 a=asa (on behalf of drivers) for checkin to Mozilla 1.5beta.
Attachment #129074 - Flags: approval1.5b? → approval1.5b+
Boris asked me to land this, and I did. Fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: