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

VERIFIED FIXED in mozilla1.0

Status

Core Graveyard
GFX
P2
normal
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: Joel Griffiths, Assigned: rods (gone))

Tracking

({regression})

Trunk
mozilla1.0
x86
Linux
regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DIGBug][eapp], URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 43583 [details]
HTML to Test and validate Hidden Select problem.
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. ***

Comment 5

17 years ago
Created attachment 45388 [details]
Scrollbar floating above overlayed layers/form elements

Comment 6

17 years ago
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. ***

Comment 10

17 years ago
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.




Comment 11

17 years ago
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
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla1.2
*** Bug 122356 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
*** Bug 109146 has been marked as a duplicate of this bug. ***

Comment 19

16 years ago
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 → ---

Comment 21

16 years ago
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
(Assignee)

Comment 22

16 years ago
This used to work.
Status: NEW → ASSIGNED
Keywords: regression
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 23

16 years ago
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.
(Assignee)

Updated

16 years ago
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. ***
(Assignee)

Updated

16 years ago
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla1.0
(Assignee)

Comment 28

16 years ago
Created attachment 76322 [details] [diff] [review]
patch

Disable and set the visibiliy of the scrollbars, if they are not disabled they
get turned back on again.

Comment 30

16 years ago
Comment on attachment 76322 [details] [diff] [review]
patch

sr=attinasi
Attachment #76322 - Flags: superreview+

Updated

16 years ago
Keywords: approval, review

Comment 31

16 years ago
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+
(Assignee)

Comment 32

16 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 33

16 years ago
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.

Comment 34

16 years ago
I'm on Linux, Build ID is 2002032717.

Comment 35

16 years ago
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

Comment 36

16 years ago
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 → ---

Comment 37

16 years ago
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

Comment 38

16 years ago
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

Comment 39

16 years ago
rods, this isn't about XBL form controls, right? It sounds like it hasn't been
fixed. Can you look at this again? Thanks.
(Assignee)

Comment 40

16 years ago
Created attachment 77482 [details] [diff] [review]
patch

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
(Assignee)

Updated

16 years ago
Status: REOPENED → ASSIGNED

Comment 41

16 years ago
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 42

16 years ago
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 43

16 years ago
Comment on attachment 77482 [details] [diff] [review]
patch

r=dcone
Attachment #77482 - Flags: review+

Updated

16 years ago
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 44

16 years ago
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+

Comment 45

16 years ago
adt1.0.0+ (on ADT's behalf) for checkin approval into 1.0.
Keywords: adt1.0.0 → adt1.0.0+
(Assignee)

Comment 46

16 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 47

16 years ago
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

Comment 48

16 years ago
yay!  The fix works in build 2002040511 on Win2k (sp2sr1).

Jake

Updated

16 years ago
Keywords: verified1.0.0

Comment 49

16 years ago
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.