form elements will not draw over absolutely positioned elements




Layout: Form Controls
17 years ago
14 years ago


(Reporter: Wayne Schroeder, Assigned: rods (gone))



Firefox Tracking Flags

(Not tracked)



(3 attachments)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.1+) Gecko/20010616
BuildID:    2001061606

Html div areas, when made visable (say in a drop down menu), will not draw over
a multi select form object.  Example: Drop down menu drops down over a select
area in a html page.  The form element cuts out part of the menu.

Reproducible: Always
Steps to Reproduce:
1.find a site with html which has dhtml drop downs source, add a multiselect below menu drop down area
3.drop down menu over multiselect

Actual Results:  multiselect stays on top of drop down menu

Expected Results:  multiselect should be below drop down menu with other elements

I can't export the html example as it is company ip.  Sorry
This may well be correct behavior -- it could be that the HTML is wrong.  Could
you provide sample markup?

Comment 2

17 years ago
Created attachment 38796 [details]
testcase showing behavior

Comment 3

17 years ago
I believe this is because multi-selects are currently drawn using native
widgets-- once we move to XBL-based form controls (bug 57209) this should be fixed.

Comment 4

17 years ago
Chatted with the reporter in #mozilla and he produced:
as an example of the code that does not work as expected (mouse over "Choice 1").
Modifying the html slightly (to give the DIV a z-index) gives:
which does work as expected.
I don't know whether the initial case should be expected to work or not.

Comment 5

17 years ago
Righto, two shorter testcases of a and b above.
Again the only difference is that in d a "z-index:2;" is specified for the popup
div. C does not set a z-index. Perhaps a z-index _needs_ to be set, but it seems
odd that the div pops over the "hellohellohello" and under the select box.
Over to someone who knows.....

Comment 6

17 years ago
Verified on
build: 2001-06-27-04-Trunk
platform: Win NT

Checked all the test cases (a,b,c, and d). Changing the component to Layout.
Component: HTML Element → Layout
Ever confirmed: true
If you add 'z-index: 1' to the stylesheet rule with selector '#floater' you will
see the effect that you expected.

However, without that declaration, I think (roc, Ian -- is this correct?) that
the form control should be under the DIV since the DIV is first in the document.
 (Is that what we do now were they normal HTML elements, or not?  If not, then
this probably isn't form-control specific.)   But changing component to HTML
form controls.  Our current behavior is certainly inconsistent.
Assignee: clayton → rods
Component: Layout → HTML Form Controls
QA Contact: bsharma → madhur
Summary: html DIV areas will not draw over form elements → form elements will not draw over absolutely positioned elements
Created attachment 42299 [details]
same as previous testcase except 'z-index: 1' added.
Hmm, OK.  I tried some normal text, and we're doing it wrong there too, so it's
to some degree the listbox form controls that are being inconsistent with
everything else they do, except I *think* it's the list boxes that are right and
everything else that's wrong (except I can't find the bug and I don't want to
try to understand this part of the spec again right now...).


16 years ago
Target Milestone: --- → Future

Comment 10

15 years ago
It seems that the bug is almos corrected, in Phoenix 4 only the scrolbars of
Select boxes appear over the divs that have an higher z-index

Comment 11

15 years ago
Created attachment 106383 [details]
Div over select box scroolbar

This shows the behaviour of displaying a div over a select box.
The scroolbars show through
The scrollbar issue got fixed when we switched over to GFX scrollbars
completely, recently.

*** This bug has been marked as a duplicate of 126263 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.