Closed Bug 46257 Opened 24 years ago Closed 21 years ago

setting overflow to hidden still triggers scrollbar

Categories

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

Product:
Core
Component:
Layout: Block and Inline
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: muteki, Unassigned)

References

Details

(Keywords: css2, perf, testcase)

Attachments

(4 files)

jsut attaching the supplied code to facilitate testing
1.12 KB, text/html
Details
To kill horizontal scrollbars or both (horizontal and vertical) on nn6.
1.21 KB, text/html
Details
to kill only the horizontal scrollbars
1.33 KB, text/html
Details
to kill the horizontal and vertical scrollbars
1.37 KB, text/html
Details
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: 24 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
*** 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: 24 years ago → 21 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.

Attachment

General

Creator:
Created:
Updated:
Size: