if body overflow is set to hidden and the position of a DIV is set to absolute, the div is invisible

VERIFIED FIXED

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: Olaf Christoffel, Assigned: roc)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.6b -
blocking1.6 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 1.6a, Firebird 20031114

Setting a the overflow of a body to hidden and adding a div to the body which
position is set to absolute will result in not showing the div.

First appearance of this bug is mozilla 1.6a. With nightly Firebird 20031114 it
is the same behaviour. Mozilla 1.5 final does not have a problem with it.

Tested on win2000 and winXP.



Reproducible: Always

Steps to Reproduce:
look at the example


Expected Results:  
div is showing with position set to absolute. body does not have scrollbars
(overflow=hidden).


example:

<html>
<body style="overflow:hidden">
<script>
window.onload=function(){
	var div = document.createElement('DIV');
	div.innerHTML ='this div should be visible!';
	div.style.height='250px';
	div.style.width='250px';
	div.style.left='10px';
	div.style.top='10px';
	div.style.backgroundColor = 'green';

	div.style.position='absolute';

	document.body.appendChild(div);
};
</script>
</body>
</html>
(Reporter)

Comment 1

15 years ago
Created attachment 135565 [details]
example
The <body> has hidden overflow, the div overflows the body.  So it should be
hidden, no?  I don't quite know why it wasn't before.

dbaron, this likely changed as the result of your change to overflow:hidden. 
Did we have the old behavior for a reason, or was it just a bug?
Well, there is this quirk (maybe even standardized in CSS 2.1) that
overflow:hidden on the body will disable scrollbars, in which case it should not
actually be applying to the body. We partially implement that...
Ah, I see... that quirk may have broken with dbaron's overflow changes...  Do
you recall where that's implemented?

Comment 5

15 years ago
Created attachment 135719 [details]
Demo of overflow:hidden with absolutely positioned elements in nested divs

It's not just overflow:hidden applied to the html/body element that has
changed. The changed behaviour also occurs when applied to two nested divs
(compare the attached testcase in Mozilla 1.5 to the latest nightly). This
behaviour changed between the nightly builds on the 16th and the 17th of
September (so I assume it is due to the checkins from bug 69355).

The new behaviour appears correct, at least from my naive reading of the CSS2.0
specs, however the pre-2003/09/17 builds shared the same behaviour as Opera
7.22. There's a section in the CSS2.1 spec (that wasn't in the CSS2.0 spec)
that seems to explain the old-Mozilla/current-Opera behaviour:

http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/visufx.html#overflow-clipping


"In certain cases, a box may overflow, meaning its content lies partly or
entirely outside of the box, e.g.:
[...]
A descendent box is positioned absolutely, partly outside the box. Such boxes
are not clipped by the overflow property on their ancestors."

So I think that the checkins from bug 69355 caused Mozilla to regress from
CSS2.1 behaviour to CSS2.0 behaviour when it comes to overflow:hidden and
absolutely positioned elements. I hope this helps, and I apologise if this
comment is wrong/obvious/redundant enough to count as spam.

Comment 6

15 years ago
*** Bug 226480 has been marked as a duplicate of this bug. ***
*** Bug 226442 has been marked as a duplicate of this bug. ***
Ok, I'm confirming this...  It did indeed break between Sept 16 morning and Sept
18 evening, consistent with the overflow:hidden changes...

As far as I can tell, overflow:hidden just didn't clip abs pos kids at all... 
but now the scrollframe does.  I think we sorta want to fix this for 1.6.  :(
Assignee: other → roc
Status: UNCONFIRMED → NEW
Component: Layout → Layout: View Rendering
Ever confirmed: true
Flags: blocking1.6?
Keywords: regression
OS: Windows 2000 → All
Hardware: PC → All
I'm not sure what's doing the clipping since the absolutely positioned frame is
a sibling of the scrollframe (well, different child lists), and the views are
siblings as well...
Flags: blocking1.6b?
Created attachment 136331 [details]
clearer testcase, perhaps
Attachment #136073 - Attachment is obsolete: true
Attachment #136331 - Attachment is patch: false
Attachment #136331 - Attachment mime type: text/plain → text/html; charset=UTF-8
My understanding of the problem here is that nsIClipView clipping and
ZPlaceholder views don't get along.  I don't quite understand how this stuff
works, and it seems like there are duplicate mechanisms, perhaps for performance.

Comment 13

15 years ago
doesn't look like this is going to make beta which will (hopefully) be going out
any minute now. 
Flags: blocking1.6b? → blocking1.6b-
Hum. I believe the behaviour we were trying to implement was "'overflow' on a
box B affects all boxes B' which for which B is the containing block".

The CSS 2.1 language isn't fully consistent with that, but maybe it's not
consistent with itself either. "Such boxes are not clipped by the overflow
property on their ancestors." --- so absolutely positioned boxes just aren't
affected by any 'overflow' settings? But then just below there's "It affects the
clipping of all of the element's content except any descendant elements (and
their respective content and descendants) whose containing block is the viewport
or an ancestor of the element." --- which would suggest that absolutely
positioned boxes *are* clipped by 'overflow:hidden' on their containing block.

That confusion is, however, unrelated to this bug. The problem here is that
nsViewManager::CreateDisplayList has always assumed that a scrolling view should
always clip all its children, even those that get reparented elsewhere. I think
long ago I was assuming that a scrolling block would always be a containing
block ancestor for its children. Presumably this has never been the case and we
just didn't notice until now.

There are two possible fixes. We could just set isClipView to false here (and
remove all the dead code):
http://lxr.mozilla.org/seamonkey/source/view/src/nsViewManager.cpp#3410
There could be performance implications. The important one is that this would
mean we would no longer *ever* generate PUSH_CLIP/POP_CLIP instructions, so
every child view that was clipped by a scrolling area would have to setup its
own clipping. These extra clipping operations might be significant for
performance on sucky graphics APIs like X11 --- I'm not sure. But it would
certainly simplify the view code nicely.

A slightly more conservative fix would be to set isClipView to
"IsClipView(aView) && (aView->GetViewFlags() &
NS_VIEW_FLAG_CONTAINS_PLACEHOLDER) == 0". This would disable the special
handling of scrolling views whenever reparented children are present. I think I
prefer this one.
> which would suggest that absolutely positioned boxes *are* clipped by
> 'overflow:hidden' on their containing block.

They are, but in the testcases given here the <body> is not the containing block
-- the <html> is.  I'd send some mail to www-style about clarifying that first
quote you gave to make it clear that that's only true if the element is not
itself an abs pos containing block...
Attachment #137114 - Flags: superreview?(dbaron)
Attachment #137114 - Flags: review?(dbaron)
Comment on attachment 137114 [details] [diff] [review]
fix like so

Did you test that this doesn't break the clipping that we do want?  If so,
r+sr=dbaron.
Attachment #137114 - Flags: superreview?(dbaron)
Attachment #137114 - Flags: superreview+
Attachment #137114 - Flags: review?(dbaron)
Attachment #137114 - Flags: review+
I think we should get this in for 1.6 if reviewers and drivers think it's safe
enough.

/be
Flags: blocking1.6? → blocking1.6+
I'll run some more tests, but clipping is really controlled by
nsView::GetClippedRect. This display list stuff is just an optimization, and was
never applied to 'overflow:hidden' elements until dbaron's change. So I think
the risk is low.
Comment on attachment 137114 [details] [diff] [review]
fix like so

roc, dbaron: good for 1.6?

/be
Attachment #137114 - Flags: approval1.6?

Comment 21

15 years ago
*** Bug 228402 has been marked as a duplicate of this bug. ***

Comment 22

15 years ago
*** Bug 228182 has been marked as a duplicate of this bug. ***

Comment 23

15 years ago
Comment on attachment 137114 [details] [diff] [review]
fix like so

a=asa (on behalf of drivers) for checkin to Mozilla 1.6
Attachment #137114 - Flags: approval1.6? → approval1.6+

Comment 24

15 years ago
This needs to land quickly if it's going to make the 1.6 branch.

Comment 25

15 years ago
I think that this is the cause of bug 212538 and (possibly) bug 170011.
I checked this patch into the trunk, 2003-12-17 13:05 -0800.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Blocks: 216353

Updated

15 years ago
No longer blocks: 216353

Updated

15 years ago
Blocks: 224134
(Reporter)

Comment 28

15 years ago
with nightly 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031218
the overflow works as we expect it :-) 
many thanks!!

i would like to mark the bug as verified if its going to work with moz 1.6 final.

Comment 29

15 years ago
-> VERIFIED FIXED

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20031219)
Status: RESOLVED → VERIFIED
*** Bug 229971 has been marked as a duplicate of this bug. ***
*** Bug 212538 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
In http://forums.mozillazine.org/viewtopic.php?t=44514 it seems this fix did not
make it into the 0.8 Mozilla Firebird branch.

Comment 33

15 years ago
Firebird 0.8 branch is not the same as Moz 1.6 branch, this time.
Please file a firebird bug on issues caused by firebird creating the 0.8 branch
so early.
*** Bug 225037 has been marked as a duplicate of this bug. ***
This checkin caused bug 232469, as far as I can tell (tested via local backout).
You need to log in before you can comment on or make changes to this bug.