234788 - css list-based menus lose hover enabled display when over a overflow:auto styled div

Status: VERIFIED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[David Anderson]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

In http://davious.org/overflowautohoverbug.html, a very simple menu system ala 
http://www.alistapart.com/articles/dropdowns/
uses an absolutely-positioned, hidden list within a list by displayed it when
the outside list item is hovered on using css li:hover ul { display: block; } rule.

However, while continuing the hover down the now displayed inner-list until you
are also over a div, which happens to have a div { overflow:auto } rule, the
browser disregards the li:hover, and the inner-list is errorneously hidden again.

Reproducible: Always
Steps to Reproduce:
1. Hover over 'Hover here'
2. Observe inner list display
3. Hover down inner list until the cursor is just above the div border
4. Observer list remains displayed
5. Hover over inner list and below the div border

Actual Results:  
The inner list becomes hidden

Expected Results:  
The inner list should not have become hidden (until I moused beyond the bottom
of the list)

Comment 1

[Rob Janssen]

Confirmed; it affects a CSS-based menu that I designed to replace the usual
javascript stuff on the website at work.

Mozilla 1.7 and Firefox are affected too; Opera 7.51 is OK.
(MSIE of course does not handle li:hover at all)

Comment 2

[koivi]

Here's what I found about this:

1. If a block element with "overflow:auto" or "overflow"scroll" (only those
overflow settings) has a hover case that overlaps it, when you mouse over it, it
cancels active hover effects.

2. If "position:absolute" is used, the z-index always seems to be bumped above
the hover z-index. For instance, if the hover effect z-index is 5, and the
absolutely positioned block element is z-index:1, the absolutely positioned
block element will always appear on top of the hover effect.

For examples, see http://www.koivi.com/bugzilla/234788.html

Browsers effected: Netscape 7.1 (Mac/PC), Mozilla 1.7.2 (Mac/PC), Firefox 0.9.3
(PC - I assume Mac as well)

Comment 3

[koivi]

Attachment: CSS Menu example with block element overflow and position (z-index) bugs

This HTML file describes & illustrates the bug behavior.

Comment 4

[koivi]

(In reply to comment #0)
> User-Agent:       
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8
> 
> In http://davious.org/overflowautohoverbug.html, a very simple menu system ala 
> http://www.alistapart.com/articles/dropdowns/
> uses an absolutely-positioned, hidden list within a list by displayed it when
> the outside list item is hovered on using css li:hover ul { display: block; }
rule.
> 
> However, while continuing the hover down the now displayed inner-list until you
> are also over a div, which happens to have a div { overflow:auto } rule, the
> browser disregards the li:hover, and the inner-list is errorneously hidden again.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Hover over 'Hover here'
> 2. Observe inner list display
> 3. Hover down inner list until the cursor is just above the div border
> 4. Observer list remains displayed
> 5. Hover over inner list and below the div border
> 
> Actual Results:  
> The inner list becomes hidden
> 
> Expected Results:  
> The inner list should not have become hidden (until I moused beyond the bottom
> of the list)

Comment 5

[Rob Janssen]

The original bug is fixed in Mozilla 1.8a4
The extra effect mentioned by koivi is not fixed in that release.
So please make sure you report that separately.

Comment 6

[koivi]

z-index problem entered as bug #264357, please confirm and vote.

Comment 7

[Martijn Wargers (dead)]

So this bug can be marked WORKSFORME?
I don't see the bug anymore in current trunk builds.

Comment 8

[David Anderson]

Neither firefox trunk builds from Dec 7th or 9th is surviving start-up.

I'll check back in a day or two and as soon as I can verify that my test case
(see URL) is passing, I'll be happy to mark it WORKSFORME.

Comment 9

[David Anderson]

Verifying WORKSFORME on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a6) Gecko/20041216 Firefox/1.0+

Comment 10

[Rob Janssen]

Unfortunately Mozilla 1.7.5 (Mozilla/5.0 (Windows; U; Windows NT 5.0; nl-NL;
rv:1.7.5) Gecko/20041217) still has this bug...

Comment 11

[Anne (:annevk)]

Please use a trunk build to test, not a stable branch. This bug was marked
worksforme with 1.8a6, you are using 1.7.5.

Comment 12

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050419
Firefox/1.0+
I am still seeing this in the testcase (Test2)
Reopen?

Comment 13

[Steve England [:stevee]]

*** Bug 252490 has been marked as a duplicate of this bug. ***

Comment 14

[Steve England [:stevee]]

*** Bug 184077 has been marked as a duplicate of this bug. ***

Comment 15

[Rob Janssen]

(In reply to comment #12)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050419
> Firefox/1.0+
> I am still seeing this in the testcase (Test2)
> Reopen?

What are you still seeing?  The original bug, or the added remark by koivi that
was moved into another bug?

As I see it here, the original bug reported here isn't fixed in the 1.7.x
versions (still present in 1.7.7) but it works OK in 1.8x

Comment 16

[Steve England [:stevee]]

Ah, thanks rob, I overlooked that comment. It's behaving as expected. Sorry for
the bugspam.