Closed Bug 46257 Opened 23 years ago Closed 20 years ago

setting overflow to hidden still triggers scrollbar

Categories

(Core :: Layout: Block and Inline, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: muteki, Unassigned)

References

Details

(Keywords: css2, perf, testcase)

Attachments

(4 files)

The following code is the revision of #45997.  This code has been tested with 
2000072108 build.  The scrollbar will appear if the inner Div has a larger area 
than the outer Div but overflow is set to be hidden.

<HTML>
<HEAD>

<STYLE>
        div.tickercontainer
        {
                top:100px;
                left:0px;
                width:452px;
                height:18px;
                overflow:hidden;
                position:absolute;
        }

        div.ticker
        {
                height:18px;
                top:0px;
                width:900px;
                position:absolute;
        }
</STYLE>

<SCRIPT>
var nStart = 444;
var nEnd = -950;
var nTimeOut = 50;
var nInc = 5;

var nLeft = nStart;

function DoMove()
{
        nLeft = nLeft - nInc;
        if( nLeft < nEnd )
        {
                nLeft = nStart;
        }

        document.getElementById('ticker').style.left = nLeft;
 
        setTimeout( 'DoMove()', nTimeOut );
}

</SCRIPT>

</HEAD>
<BODY>
<DIV id='tickercontainer' CLASS='tickercontainer'>

<DIV ID='ticker' CLASS='ticker'>
Blah blah blah blah.  Blah blah blah.  Blah blah blah blah?  Blah blah, "blah 
blah blah."  Blah, blah blah blah?  Blah blah: blah.  Blah blah blah...</A>
</DIV>
</DIV>

<SCRIPT>

DoMove();

</SCRIPT>

</BODY>
</HTML>
verified with 080108 m18 build on NT
Status: UNCONFIRMED → NEW
Ever confirmed: true
Re-assigning 7 bugs from Clayton's bug list to Heikki for further triage.
Assignee: clayton → heikki
I voted for this bug, because it makes hiding unwanted scrollbars in Mozilla  
impossible. For AFAIK the only way to achieve this is:

document.body.style.height=innerHeight;
document.body.style.overflow="hidden";

(That's how it also works in Internet Explorer. With NN4, we used to set
   document.height=innerHeight;
but document.height is now read-only.)
I do not think this feature is that common (but please correct me if I am 
wrong). Also it does not limit the usability of the application. It is basically 
a cosmetic glitch. Based on these facts I am going to Future this bug.

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
I don't agree. 
Whenever you use advanced DHTML, you will have things partly or entirely outside 
 the window area. And then it looks very bad if there is a scrollbar that keeps 
adjusting itself as e.g. the animation goes on.
The question of how to avoid this effect comes up at least twice a month in 
de.comp.lang.javascript. deja.com shows 300 recent results for "hide scrollbar".
massive update for QA contact.
QA Contact: petersen → lorca
Is this views(?), reassigning.
Assignee: heikki → kmcclusk
Status: ASSIGNED → NEW
Component: HTML Element → Views
QA Contact: lorca → petersen
I don't think it's views.  It's probably layout.
This is a major problem. We are not dealing in the realm of static HTML with a 
linear page. Often in advanced layouts we want to hide portions of content such 
as a custom scrolling DIV layer or to dynamically position an image off screen 
with out the auto scroll bars poping up.  More importantly this has been tried 
and true practice since early NS 4x & IE 4x - what 3 to 4 years old now. So many 
sites use DHTML now and much of that success is the fact that we can control the 
display of the scrollbars. 
I suspect this would be fixed by changing some of the treatment of
|aMetrics.mOverflowArea| (and perhaps also the NS_FRAME_OUTSIDE_CHILDREN state
bit) in |nsBlockFrame::Reflow| to depend on the overflow property.
Scrollbars are no longer triggered with 12/13/2000 build on WINNT.
Marking Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
This bug should be reopened. At least it is still around in M0.7/Win98.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Agreed.  Still exists on current Linux build.
But this is really a layout bug.  ->buster
Assignee: kmcclusk → buster
Status: REOPENED → NEW
Component: Views → Layout
what is the workaround for this bug? the following reloads the page, but does 
not stop scrollbars from appearing (Netscape 6.01 on Windows):
document.body.style.height = window.innerHeight;
document.body.style.overflow = "hidden";
Ive been trying to hide scrollbars in XUL elements such as iframe, tree and box 
and use  scrollbar element elsewhere in screen design.

Certainly this bug makes XUL application design impossible because unwanted 
duplicate scrollbars appear causing total confusion

Makes the XUL window look like a real dog's dinner 

Its not just cosmetic!!!.


I presume this does not have to be raised a seperate (XUL) bug ?
Keywords: css2
I dont see any problems in the testcase, is this fixed?
No.  Look at the bottom of the page when loading the first testcase.

(I think I might own a bug that's a duplicate of this or vice versa.)
I have to say that its a real dissapointment that this bug is marked as Future. 
Most of the dhtml-applications that you make requires to hide the scrollbars. 

For example, a simple drag and drop looks really horrible when you drag an
object near the scrollbars. It just destroys the impression of your dhtml
applications. 

I am really exicted about all the cool stuff that you can make with the
fantastic DOM support in Mozilla. But with this bug its a real pitty that some
dhtml-stuff will look like shit with objects that have a position outside the
visible area.
Reassigning.  This may get duped into bug 93905, which is related.
Assignee: buster → hyatt
This should have stayed where it was.  Hyatt is working on the style system 
itself, not all the layout code that uses it.
dbaron: "where it was" was buster.  I'll send it to karnaze and let him 
reassign as needed.
Assignee: hyatt → karnaze
Another example - with vertical scrolling this time:
http://www.cs.brown.edu/courses/cs051/
resource:///res/samples/test13.html
Look at the scrollbars...
-->attiansi
Assignee: karnaze → attinasi
I think that this bug has something to do with absolute positioning because
the scrollbars are right in this test case
http://bugzilla.mozilla.org/attachment.cgi?id=27275&action=view
but not in this one
http://bugzilla.mozilla.org/attachment.cgi?id=12242&action=view

The only difference between these test cases is that the 'ticker' DIV element is
relatively positioned in the former and absolutely positioned in the latter. My
suspicions have been confirmed because just changing the 'ticker' elements's
positioning to relative in the latter test case works around this bug.
Hey people I got a good news -- I think.
I was able to get the original testcase in this bug to work (i.e. hide the
scrollbar) by changing overflow:hidden to overflow:-moz-scrollbars-none
I know IE doesn't support it (it has overflow-x and overflow-y instead, see bug
72747), but it's better than nothing.
Now the task is to figure out the difference between overflow:hidden and
overflow:-moz-scrollbars-none. 
Note that we also support overflow:-moz-scrollbars-vertical/horizontal.
Hope this helps.
Adding overflow:-moz-scrollbars-none made the whole page content dissapear...
The only thing you saw was the scrollbars.
*** Bug 110963 has been marked as a duplicate of this bug. ***
I noticed that 
<body style="overflow:hidden;">
now hides the horizontal scrollbars. Still there is vertical though.
Keywords: topembed
Keywords: topembed
This WFM with both Windows 2000 and XP build 20020325.
Sorry, 
what i meant was that setting the overflow:hidden; in the body tag now works.
The first testcase still has scrollbars.
Is this a duplicate of bug 45597?
Is this a duplicate of bug 45597?
It would be nice with a testcase that was as reduced as it possibly can be,
still showing the bug.
Here's a very simple testcase, with CSS only, that still triggers scrollbars:
http://13thparallel.org/temp/moz_overflow_hidden.htm

I'm seeing both horizontal and vertival scrollbars. Using this version:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417

This is a very common bug, and you don't even need DHTML to cause the problems, 
just a bit of CSS layout. I think scrollbars are not merely a visual effect, 
they can cause usability problems too. I think it looks strange to have such 
flaky scrollbar control in a release candidate, and this should really be fixed 
for 1.0.
Sorry for that post there... I have been overzealous. My testcase *should* 
probably display the scrollbars for invisible overflow.

I think the original problem is fixed, which is really cool... because when the 
overflow of the body is set to hidden, there are no longer any scrollbars :)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020509

I'm having a problem with content disappearing that seems to be related to this 
bug.  Here's a minimal example:

http://server1.triplecom.net/moztest/minimal.html

When I size the window so that the vertical and horizontal scrollbars appear, 
the word "test" disappears. Increasing the window size reverses the problem.  
If, while both scrollbars are visible, I use the horizontal scrollbar, screen 
corruption results.

Other examples:

http://server1.triplecom.net/moztest/test.html
http://server1.triplecom.net/moztest/testa.html

Even the toggle button in test.html disappears, depending on the window size.  
testa.html is animated to show how intermediate values for style.left affect 
the left-hand image before hiding it completely.

Removing the background-color from the outer DIV seems to get rid of the 
content hiding problem, but doesn't affect the scrollbars.  Switching the inner 
DIV to relative positioning fixes everything, like others have said.
Blocks: 38639
Blocks: 140729
No longer blocks: 140729
*** Bug 140729 has been marked as a duplicate of this bug. ***
This bug is causing some very noticeable performance problems on DHTML things
like scrollers and bouncing things that are very commonly used.
Severity: normal → major
Keywords: 4xp, mozilla1.1, perf
OS: Windows NT → All
Hardware: PC → All
Keywords: mozilla1.2
Blocks: 21762
Depends on: 170330
Blocks: 145141
*** Bug 105618 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3, testcase
Depends on: 45597
Blocks: 52063
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P3 → --
QA Contact: cpetersen0953 → ian
Target Milestone: Future → ---
Blocks: 203448
I dont get any scrollbars anymore on the first testcase, is this fixed?
Can anyone verify?

Using Gecko/20031116 Firebird/0.7+
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031028

Though I get a scrollbar with the second test case, but I think that one is
completely invalid and should be removed or marked that way.
*** Bug 226023 has been marked as a duplicate of this bug. ***
I went through all dupes and testcase and this problem does not occur anymore.
try http://news.ft.com/markets from bug 226023.  The bug is still there for me.
About http://news.ft.com/markets, reason you see the scrollbar in Mozilla and
not IE is because (take from line 66):
if(document.all)
{
document.write("#innerDiv{
position:relative;z-index:1;left:0;height:25;layer-background-color:FFFFFF;overflow:hidden;}")
}
else{document.write("#innerDiv{position:relative;z-index:1;left:0;height:25;layer-background-color:FFFFFF;}")
}

So overflow:hidden is not even set for Mozilla.
WFM too - on winxp pro with build 2003102804
Marking as WORKFORME, pleae reopen if you can reproduce
Status: NEW → RESOLVED
Closed: 23 years ago20 years ago
Resolution: --- → WORKSFORME
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.