Closed
Bug 4315
Opened 26 years ago
Closed 25 years ago
Scrolling views do not honor CSS visibility property correctly
Categories
(Core Graveyard :: GFX, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M5
People
(Reporter: kmcclusk, Assigned: kmcclusk)
Details
Elements with scrollbars display the scrollbar even when their CSS visibility
property is set to hidden.
Testcase
<html>
<body>
<div style="visibility:hidden; width:100px; height:100px; overflow:scroll;">
<p>option 1</p>
<p>option 2</p>
<p>option 3</p>
<p>option 4</p>
<p>option 5</p>
</body>
</html>
Expected behavior: Nothing should be displayed
Actual behavior: The <P> text is not displayed, but horizontal and vertical
scrollbars are displayed.
This prevents frame-based comboboxes from working properly.
The drop-down list for the combobox always displays a scrollbar, even when the
list has not be dropped down.
It also causes frame-based listboxes to display scrollbars when their visibility
property is set to hidden.
Michael, I fixed the scroll-frame code so that it passes in
nsViewVisibility_kHide when calling Init() on the scrolling view. Now the
scrolling view itself has "v=0", but the scrollbars are still visible
|
Assignee | |
Comment 3•26 years ago
|
||
Michael, I don't have a fix for this. If you can fix it before you go that would
be great. Otherwise I'll fix it. I think the best way to fix this is for the
scrollbar components (mClipView, mHorizontalScrollbarView,
mVerticalScrollbarView, mCornerView.) to look at both their visibility flag and
the mScrollingView's visibility flag to determine whether they are visible.
Since each of these are not separate classes maybe there should be a general
mechanism to tell a nsIView that it should consider it's parent view when
determining visibility.
/**
* Determines what is returned from GetVisibility.
* @param aParentControlsVisibility if PR_TRUE this view will not be visible
* unless it's parent is also visible. if PR_FALSE the parent visibility has
no effect on this view's visibility.
*/
NS_IMETHOD SetParentControlsVisibility(PRBool aParentControlVisibility) = 0;
If SetParentControlsVisibility(PR_TRUE) is called then the The GetVisibility
method will return PR_FALSE if the parent view is not visible, or the view
itself has been marked as invisible.
What do think of this solution?
that's what the inherited visibilty was supposed to do. troy and i decided that
we didn't need this because layout was already doing the work. i'd perfer not
to add the same functionality into the view system. the thing about this that's
ugly is that if you inherit visibility you need to do a lot of tree walks to
keep things in sync if the api is truly general. for what we need to do here,
it's probably better to just have the scrolling view maintain the visibility of
it's kids properly (since noone can ever see them anyways).
|
|
Assignee | |
Comment 5•26 years ago
|
||
Ok, I'll go ahead and make the nsScrollingView explicitly manage the visibility
of the mClipView, mHorizontalScrollbarView, mVerticalScrollbarView and
mCornerView.
|
|
Assignee | |
Updated•26 years ago
|
Assignee: michaelp → kmcclusk
Target Milestone: M5
|
|
Assignee | |
Comment 7•26 years ago
|
||
Reassigning to myself.
|
|
Assignee | |
Updated•26 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 8•25 years ago
|
||
Fixed in April 16, 99: 12:43 am build.
Added code to manage the visibility of the ScrollingView's components
(mClipView, mHScrollBarView, mVScrollBarView, mCornerView.)
|
||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 9•25 years ago
|
||
Fixed in the April 23rd Build.
|
||
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•