Closed Bug 92333 Opened 23 years ago Closed 22 years ago

[PATCH]Select box scrollbar is not hidden with visibility:hidden property.

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: joelgriffiths, Assigned: rods)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [DIGBug][eapp])

Attachments

(3 files, 1 obsolete file)

HTML to Test and validate Hidden Select problem.
836 bytes, text/html
Details
Scrollbar floating above overlayed layers/form elements
5.21 KB, text/html
Details
patch
6.06 KB, patch
dcone
: review+
attinasi
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062823

Cannot hide the scrollbar on select boxes. This can be specified as a style
property like <select name="embedded_style" size="6"
style="width:250;visibility:hidden;"> or if can be set via JavaScript.

Here is an example:
<HTML>
<HEAD>
<script>
function clearSelectBox () {
    document.getElementById("viaJavaScript").style.visibility = 'hidden';
    }
</script>
 
</HEAD>
<BODY onLoad="clearSelectBox();">
<H1>Test Visibility property for multiple selects</H1>
<div id="DetailsLayer" class="TabStyle">
 <form>
    <select name="embedded_style" size="6" style="width:250;visibility:hidden;">
        <option>item1</option>
        <option>item2</option>
        <option>item3</option>
    </select>
 
    <BR>
 
    <select name="viaJavaScript" size="6" id="viaJavaScript">
        <option>item1</option>
        <option>item2</option>
        <option>item3</option>
    </select>
 
    <BR>
 
    <select name="normal" size="6">
        <option>item1</option>
        <option>item2</option>
        <option>item3</option>
    </select>
 
 </form>
</div>
</HTML>

Reproducible: Always
Steps to Reproduce:
1.Load the above html into a browser, you will see the select scrollbar, but not
the select options box. 
2.
3.

Actual Results:  Only the options are hidden. The scrollbar is not.

Expected Results:  Everything should be hidden when this property is set.

This problem exists with both <select> and <select multiple>. I cannot think of
any workaround for this bug. It appears to match an older bug# 58212.
Over to compositor.  I see this with linux build 2001-07-25-08
Status: UNCONFIRMED → NEW
Ever confirmed: true
over to compositor for real
Assignee: jst → kmcclusk
Component: DOM Style → Compositor
QA Contact: ian → petersen
*** Bug 92863 has been marked as a duplicate of this bug. ***
The select element's scrollbar also floats above layers and form elements that
are overlayed above the select box.

The 2nd attached file shows this.

It contains a DHTML  tabbed dialog layout with 4 "tabs". Each tab, when clicked
brings up its associated content (zindex=4, visibility=visible) and drops the
"current Tab" to the back, hiding it's content (zindex=1,visibility=hidden). 

Tab 1's content contains a select box. Tab 2 contains a text input, and text
area. Tabs 3 & 4 are empty.

Reassigning to Rod.
Assignee: kmcclusk → rods
*** Bug 102202 has been marked as a duplicate of this bug. ***
*** Bug 102745 has been marked as a duplicate of this bug. ***
Would it be possible to fix this for 0.9.5? It's one of the last remaining big
hurdles for using the browser with complex DHTML web pages.





Marking as a DIGBug (which means that the Dynamic Interface Group in AOL
products is interested in a fix) in the status whiteboard because bug 92863 got
marked as a duplicate of this bug.
Whiteboard: DIGBug
*** Bug 105933 has been marked as a duplicate of this bug. ***
*** Bug 106218 has been marked as a duplicate of this bug. ***
*** Bug 100994 has been marked as a duplicate of this bug. ***
*** Bug 110574 has been marked as a duplicate of this bug. ***
Looks like the only way to kill this is to XBL-ify the <select>....
Depends on: 112713
Target Milestone: --- → mozilla1.2
*** Bug 122356 has been marked as a duplicate of this bug. ***
*** Bug 109146 has been marked as a duplicate of this bug. ***
Marking eapp to track bugs which affect Web Application developers in Enterprise
environments. This is a higly visible, PITA for everyone. 

When will the xbl replacement for select be available?
Whiteboard: DIGBug → DIGBug eapp
Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Keywords: nsbeta1+
Whiteboard: DIGBug eapp → [DIGBug][eapp]
Target Milestone: mozilla1.2 → ---
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Keywords: nsbeta1+ → nsbeta1
This used to work.
Status: NEW → ASSIGNED
Keywords: regression
Target Milestone: --- → mozilla0.9.9
As far as I can tell this isn't a Listbox issue it is a generic issue of the
ScrollFrame not hiding the scrollbar. I spent some time on this and from what I
tell it looked like the scrollbar's native window was being hidden.

So basically I still don't know what is wrong or how much time it will take to
fix it.
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 126295 has been marked as a duplicate of this bug. ***
Bulk moving all nsbeta1 nominations to Moz1.1.  If the nomination is approved it
will be marked nsbeta1+ and moved to the Mozilla1.0 milestone.
Target Milestone: mozilla1.0 → mozilla1.1
*** Bug 126541 has been marked as a duplicate of this bug. ***
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla1.0
Attached patch patch (obsolete) — — Splinter Review 
Disable and set the visibiliy of the scrollbars, if they are not disabled they
get turned back on again.
Comment on attachment 76322 [details] [diff] [review]
patch

sr=attinasi
Attachment #76322 - Flags: superreview+
Keywords: approval, review
Comment on attachment 76322 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76322 - Flags: approval+
fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Which (if any) nightly build contains that fix? I tried the ones from
http://ftp.mozilla.org/pub/mozilla/nightly/latest/ and
http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk
(http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz
with the 27-Mar-2002 17:32 timestamp) and the scollbars are still visible in
both testcases. I'm using the non-XBL form controls.
I'm on Linux, Build ID is 2002032717.

I'm using build 2002032708 on Win2k (SP2sr1)

This is not fixed at all.  The testcases look no different than before the 
fix.  Did it actually get checked in?  If the fix works, then it most certainly 
did *not* get checked in.

Like Anti, I am using non-XBL form controls.

Jake
I'm reopening this since neither of the testcases that are supposed to work with
this fix actually do and it has been 3 days since this fact was reported ( see
comment 33 and comment 35 ) with no reponse from developers.

Being that this seems to be an important bug in the eyes of content providers
such as AOL ( see comment 11 and comment 20 ), I would think that the fact that
this doesn't yet work even after a supposed fix would get some attention. 
Hopefully this is just an oversight and a proper fix will be applied.  This
should be a 1.0 blocker.

Also, with the most recent build 2002032916 on Win2k (sp2sr1) I can't seem to
enable xbl form controls.  I was trying to test whether this bug was fixed for
xbl controls only and not native controls, but xbl controls never showed up even
after selecting "use xbl controls" in preferences/debug and restating Mozilla. 
One thing I did that might have messed things up was that first after I selected
to use xbl controls, I tried seeing what would happen if I selected it and just
reloaded the page.  What I saw was invisible form controls.  So, I closed
Mozilla and restarted it.  I don't know if that has anything to do with not,
now, being able to use xbl form controls, but I  thought I'd mention it just in
case.

Jake
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ok, I think I may have spoken too early.  The default styling for xbl controls
must have changed which was why I thoght that I hadn't switched to them.

With XBL controls turned on, both testcases work as expected.  This leads me to
believe that the fix was XBL only.

I am leaving this bug open because I doubt that XBL controls will be turned on
by default the 1.0 release.  As such, this should be made to work in native
controls as well.

If it is truly impossible to do this, please state that fact and the reason why
this is so.  If this is the case, then go ahead and re-resolve this bug.  If it
*is* possible to fix this for native controls, then it really should be before
1.0 since the current fix won't really help developers until XBL controls are
the default.

Jake
Component: GFX Compositor → Form Submission
Ok, really sorry for the spam, but I accidentally switched the component to form
submission.  Really sorry about that.  Switching back...

Jake
Component: Form Submission → GFX Compositor
rods, this isn't about XBL form controls, right? It sounds like it hasn't been
fixed. Can you look at this again? Thanks.
Attached patch patch — — Splinter Review 
This backs out the previous patch and just check to see if it is also a
listControlFrame to see if it should set the visibility to false in
nsContainerFrame (low risk)
Attachment #76322 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Comment on attachment 77482 [details] [diff] [review]
patch

sr=attinasi - please update the comment 6 lines above that change too, to
reflect that it is not just the scrollFrame that needs this (in fact it might
be better to explain why these two special cases are necessary anyway).
Attachment #77482 - Flags: superreview+
Comment on attachment 77482 [details] [diff] [review]
patch

sr=attinasi - please update the comment 6 lines above that change too, to
reflect that it is not just the scrollFrame that needs this (in fact it might
be better to explain why these two special cases are necessary anyway).
Comment on attachment 77482 [details] [diff] [review]
patch

r=dcone
Attachment #77482 - Flags: review+
Keywords: adt1.0.0
Summary: Select box scrollbar is not hidden with visibility:hidden property. → [PATCH]Select box scrollbar is not hidden with visibility:hidden property.
Comment on attachment 77482 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77482 - Flags: approval+
adt1.0.0+ (on ADT's behalf) for checkin approval into 1.0.
Keywords: adt1.0.0 → adt1.0.0+
fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
ummm...  I'm using build 2002040503 on Win2k (sp2sr1) and I still see the
scrollbars in the test cases.  The fix was checked in around 4:20am, shouldn't
that have gotten into a build that was posted to the nightly builds at around
7:50am?

I guess I'll retest with this afternoon's builds when they get posted.

Jake
yay!  The fix works in build 2002040511 on Win2k (sp2sr1).

Jake
Keywords: verified1.0.0
Verified on OS X trunk (2002-04-12-03) and Window ME trunk (2002-04-12-06).
Status: RESOLVED → VERIFIED
*** Bug 138167 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: