350678 - Relatively positioned <input> elements can't be focused with mouse when positioned over absolutely positioned div (using z-index)

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Francois P.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

When there are overlapping elements on the page, the one that could receive some INPUT won't get the focus.

Reproducible: Always

Steps to Reproduce:
1. Load the attached test file.
2. Try to select an option in the "Choice #1" SELECT > it will work.
3. Now try to select an option in the "0" SELECT > it WON'T work.
The test file gives more details on what does and does not work.

Actual Results:  
INPUT/SELECT elements won't get focus when activated by clicking somewhere inside the black area, but will if you click on them outside on that zone.

Expected Results:  
INPUT/SELECT elements should get focus everytime.

Some friends of mine were able to reproduce this under both Mac & Linux:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060802 Mandriva/1.5.0.6-1.4.20060mdk (2006.0) Firefox/1.5.0.6

Comment 1

[Francois P.]

Attachment: Reporter testcase

Comment 2

[Francois P.]

(In reply to comment #1)
> Created an attachment (id=236051) [edit]
> Reporter testcase
> 

Argh, it seems there was a problem during the transfer of the file.
The last lines should be read as:
</body>
</html>

Should I recreate a new attachment?
The URL given does show the problem anyway.

Comment 3

[Hermann Schwab]

Attachment: Reporter's testcase

added the mutilated file's end, file validates.

Comment 4

[Hermann Schwab]

The black area is z-index:1, the inputs are z-index:2

Using the tab key you can focus anywhere, using the mouse outside the black area you move focus, using the mouse inside the black area focus is lost.

Comment 5

[Martijn Wargers (dead)]

There is a div with style="overflow: visible; z-index: 1; position: absolute; left: 163px; top: 72px; width: 240px; height: 160px;" that is overlaying everything, so I think this is invalid.

Comment 6

[Martijn Wargers (dead)]

See http://www.w3.org/TR/CSS21/visuren.html#q29
and especially: http://www.w3.org/TR/CSS21/zindex.html
point 8: "Stacking contexts formed by positioned descendants with z-indices greater than or equal to 1 in z-index order (smallest first) then tree order."
The transparent div is later in the tree order so is higher in the stacking order, so will be painted on top.

Comment 7

[Hermann Schwab]

(In reply to comment #6)
> See http://www.w3.org/TR/CSS21/visuren.html#q29
> and especially: http://www.w3.org/TR/CSS21/zindex.html
> point 8: "Stacking contexts formed by positioned descendants with z-indices
> greater than or equal to 1 in z-index order (smallest first) then tree order."
> The transparent div is later in the tree order so is higher in the stacking
> order, so will be painted on top.
> 

I accept this reasoning for not reaching elements by using the mouse, 
but why can I reach the same elements using the tab key? 
is this making sense, according to a RFC, or just happening, a side-effect?

Comment 8

[Martijn Wargers (dead)]

(In reply to comment #7)
> I accept this reasoning for not reaching elements by using the mouse, 
> but why can I reach the same elements using the tab key? 
> is this making sense, according to a RFC, or just happening, a side-effect?

Yes, that makes sense, although it's kinda weird, I know. See bug 102695, which would make this bug not appear by making transparent elements transparent to event.

Comment 9

[Francois P.]

(In reply to comment #5)
> There is a div with style="overflow: visible; z-index: 1; position: absolute;
> left: 163px; top: 72px; width: 240px; height: 160px;" that is overlaying
> everything, so I think this is invalid.
> 

The DIV is black, so it should either be rendered on top of the input elements or allow for mouse events to still occur IMHO.

Comment 10

[Martijn Wargers (dead)]

(In reply to comment #9)
> The DIV is black, so it should either be rendered on top of the input elements
> or allow for mouse events to still occur IMHO.

Why do you say that? The input elements are inside the black div, so they shouldn't be rendered under the black div.

Comment 11

[Francois P.]

Oops, sorry, I misunderstand what you said.

Something strange still remains though:
>The transparent div is later in the tree order so is higher in the stacking
> order, so will be painted on top.
1) There is no transparent div, the only div here is solid black
2) The DIV's z-index may be 1, but the FORM's z-index is 2...
So shouldn't the form be rendered on top instead?
Well, it actually is rendered on top of the DIV, it just doesn't receive mouse events...

Comment 12

[Francois P.]

I also forgot to mention that I also test other browsers (IE7 & Opera) and they did not reproduce the testcase.
So I guess there eiter both wrong about that or the problem is Gecko-related...

Comment 13

[Martijn Wargers (dead)]

(In reply to comment #11)
> 1) There is no transparent div, the only div here is solid black

There is a transparent div, see the source:
	<div style="  z-index:	1;
  position:	absolute;
  left:			163px;
  top:			72px;
  width:		240px;
  height:		160px;
  overflow:	visible;"></div>
It doesn't have a background-color, so it's transparent (you can easily see this with the dom inspector).

> 2) The DIV's z-index may be 1, but the FORM's z-index is 2...
> So shouldn't the form be rendered on top instead?

No, see http://www.w3.org/TR/CSS21/visuren.html#q29
Any absolute positioned element with a z-index other than auto is creating a new local stacking context, so stacking levels are recalculated from that element.

It's talking about positioned _descendants_

> Well, it actually is rendered on top of the DIV, it just doesn't receive mouse
> events...

It's rendered on top of the black div, but not on top of the transparent div.