The default bug view has changed. See this FAQ.

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

VERIFIED WORKSFORME

Status

()

Core
CSS Parsing and Computation
VERIFIED WORKSFORME
13 years ago
12 years ago

People

(Reporter: David Anderson, Assigned: dbaron)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME, URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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)
Whiteboard: DUPEME

Comment 1

13 years ago
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

13 years ago
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

13 years ago
Created attachment 161300 [details]
CSS Menu example with block element overflow and position (z-index) bugs

This HTML file describes & illustrates the bug behavior.

Comment 4

13 years ago
(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

13 years ago
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

13 years ago
z-index problem entered as bug #264357, please confirm and vote.
So this bug can be marked WORKSFORME?
I don't see the bug anymore in current trunk builds.
(Reporter)

Comment 8

13 years ago
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.
(Reporter)

Comment 9

12 years ago
Verifying WORKSFORME on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a6) Gecko/20041216 Firefox/1.0+
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME

Comment 10

12 years ago
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

12 years ago
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.
Status: RESOLVED → VERIFIED
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?
*** Bug 252490 has been marked as a duplicate of this bug. ***
*** Bug 184077 has been marked as a duplicate of this bug. ***

Comment 15

12 years ago
(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
Ah, thanks rob, I overlooked that comment. It's behaving as expected. Sorry for
the bugspam.
You need to log in before you can comment on or make changes to this bug.