Closed Bug 92333 Opened 23 years ago Closed 23 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.
(deleted), text/html
Details
Scrollbar floating above overlayed layers/form elements
(deleted), text/html
Details
patch
(deleted), 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) (deleted) — — 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: 23 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 (deleted) — — 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: 23 years ago → 23 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: