Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

()

Core
Layout: R & A Pos
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Andy Stone, Assigned: Mats Palmgren (vacation - back in August))

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch])

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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).

Comment 1

14 years ago
Created attachment 129058 [details]
example from comment 0

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
Created attachment 129061 [details]
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
(Reporter)

Comment 5

14 years ago
Also, overflow:scroll has the same problem.
All the others work.

Comment 6

14 years ago
-> All/All (OS X)
OS: Linux → All
Hardware: PC → All
Created attachment 129067 [details]
Testcase #2 (overflow:scroll)
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]
Created attachment 129068 [details] [diff] [review]
Patch rev. 1

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+
Created attachment 129074 [details] [diff] [review]
Patch rev. 2

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 13

14 years ago
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 14

14 years ago
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
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.