86263 - form elements will not draw over absolutely positioned elements

Status: RESOLVED DUPLICATE of bug 126263

(Core :: Layout: Form Controls, defect)

Description

[Wayne Schroeder]

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
2.save 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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This may well be correct behavior -- it could be that the HTML is wrong.  Could
you provide sample markup?

Comment 2

[Jason Johnston]

Attachment: testcase showing behavior

Comment 3

[Jason Johnston]

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

[Paul McGarry]

Chatted with the reporter in #mozilla and he produced:
http://homepages.tig.com.au/~mcgarry/moz/86263-a.html
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:
http://homepages.tig.com.au/~mcgarry/moz/86263-b.html
which does work as expected.
I don't know whether the initial case should be expected to work or not.

Comment 5

[Paul McGarry]

Righto, two shorter testcases of a and b above.
http://homepages.tig.com.au/~mcgarry/moz/86263-c.html
http://homepages.tig.com.au/~mcgarry/moz/86263-d.html
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

[bsharma]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: same as previous testcase except 'z-index: 1' added.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...).

Comment 10

[João Nelas]

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

[João Nelas]

Attachment: Div over select box scroolbar

This shows the behaviour of displaying a div over a select box.
The scroolbars show through

Comment 12

[Boris Zbarsky [:bzbarsky]]

The scrollbar issue got fixed when we switched over to GFX scrollbars
completely, recently.

*** This bug has been marked as a duplicate of 126263 ***