Closed
Bug 203598
Opened 22 years ago
Closed 22 years ago
overflow:hidden and child with position:absolute cause BODY to resize! Only in Mozillas!
Categories
(Core Graveyard :: GFX, defect)
Core Graveyard
GFX
Tracking
(Not tracked)
People
(Reporter: dtesler, Assigned: kmcclusk)
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: all
If a visual container has overflow:hidden and its component has
position:absolute Mozilla (any version) resizes BODY! IE6 works fine. May be
related to BUG #78087.
Reproducible: Always
Steps to Reproduce:
1. make div (id="divContainer") with position:absolute; overflow:hidden.
2. make a child div (id="divComponent") with position:absolute.
3. Specify width and height for Container and Component so that Component's ones
are larger.
Actual Results:
BODY shows scrollbars. When Component enlarged, BODY enlarged too!
Expected Results:
Should not affect BODY or any other parent of the Container! Works fine with IE.
Doesn't in ALL Mozillas.
However, if Component's position is 'relative' behaves as expected!
May be related to the bug #78087. However, the bug's fix doesn't work here.
|
||
Comment 2•22 years ago
|
||
Those are not the <body> scrollbars. They're the viewport scrollbars. Not the
same thing at all. Put a border or background on the body and you can see that
it's not resizing at all.
Marking dup of bug 45597
*** This bug has been marked as a duplicate of 45597 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
This is a more general and stronger case! It affect ANY visual container on ANY
level of CSS stacking order. If overflow:auto extra space passed up to the
hierarchy. If container's overflow:scroll everything works fine!
Dear Boris,
Look at the attachment above! It proves my case and makes it MUCH stronger!
This is a really big bug! Also, it has more in common with the bug #78087, at
least, in my opinion.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
|
|
||
Comment 5•22 years ago
|
||
Um... I'm not saying it's not a bug. I'm just saying that it's the SAME bug as
bug 45597. Bug 78087 has nothing whatsoever to do with scrollbars or sizing of
anything, so it could hardly be this bug...
*** This bug has been marked as a duplicate of 45597 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Boris,
It's OK with me. However, look at the description of bug #45597! It has nothing
to do, in my opinion, with setTimeout. It has everything to do with CSS STACKING
ORDER.
I honestly think that my test case is pure and show the problem and its cause!
Also, I love Mozilla and wish it the best. In 95% of cases it just much more
advanced than IE. However, it is that 5% that sometimes make it inacceptable to
regular Web developers. And it makes difficult for us, entusiasts, move it through.
This is the one of these cases!
Sincerely,
David
|
|
||
Comment 7•22 years ago
|
||
It has nothing to do with stacking order, and everything to do with scrollbars
and overflow handling....
Fine!
But change position from 'absolute' to 'relative' and it works with ANY
overflow! :)
One more thing. It apparently propagates additional space up the hierarchy.
Nicely bubbles, so to speek. In this test there is the chierarchy:
html-body-divMain-divContainer-divComponent. divContainer and divMain both have
overflow:hidden. So body gets additional space.
|
||
Updated•17 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•