Closed Bug 225811 Opened 21 years ago Closed 21 years ago

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

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: silicon, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

example
413 bytes, text/html
Details
Demo of overflow:hidden with absolutely positioned elements in nested divs
929 bytes, text/html
Details
clearer testcase, perhaps
577 bytes, text/html; charset=UTF-8
Details
fix like so
1.75 KB, patch
dbaron
: review+
dbaron
: superreview+
asa
: approval1.6+
Details | Diff | Splinter Review
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>
Attached file 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?
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.
*** 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...
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.
doesn't look like this is going to make beta which will (hopefully) be going out any minute now.
Flags: blocking1.6b? → blocking1.6b-
Blocks: 225037
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?
*** Bug 228402 has been marked as a duplicate of this bug. ***
*** Bug 228182 has been marked as a duplicate of this bug. ***
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+
This needs to land quickly if it's going to make the 1.6 branch.
I think that this is the cause of bug 212538 and (possibly) bug 170011.
Blocks: 176772
I checked this patch into the trunk, 2003-12-17 13:05 -0800.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Blocks: 216353
No longer blocks: 216353
Blocks: 224134
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.
-> 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. ***
In http://forums.mozillazine.org/viewtopic.php?t=44514 it seems this fix did not make it into the 0.8 Mozilla Firebird branch.
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).
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: