646757 - List item in css-drop down menu losing hover when moving in nested list (sub menu)

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[j.gonser]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

When moving mouse in sub menue (nested list) firefox is loosing the hover. The effect is that the menue is closed or the fade-in effect (jQuery) fires again. Correct behaviour should be to keep hover when moving in nested list.

The error can best be seen when moving the mouse slowly down to the sub menue.

The site uses xhtml 1.0 strict and there are no XHTML, CSS and JavaScript errors when validating the site

The menue works fine until Firefox 3.6, Chrome 8/9/10/, Internet Explorer 7/8/9, Safari 4/5 and Opera 10/11.

Reproducible: Always

Steps to Reproduce:
1. Move mouse to horizontal menue bar
2. Move mouse slowly down to sub menue
Actual Results:  
Menue will close or fade-in effect fires again. Closing or Fading occurs randomly.

Expected Results:  
Menue should stay open and sub menue should be faded-in once.

Examples of XHTML menue structure and jQuery fade-in JavaScript Code:

<!-- HTML Codesnippet-->
<ul class="dropdown dropdown-horizontal" id="globnav">
	<li>
		<span class="dir">Guided Tours</span>
		<ul class="fadeEffect" style="display: none; visibility: hidden;">
			<li class="first">
				<a href="/cbx/cms/DE/DE/web/home/guided_tours/guided_tours_management">Management</a>
			</li>
			<li>
				<a href="/cbx/cms/DE/DE/web/home/guided_tours/guided_tours_produktdatenpflege">Produktdatenpflege</a>
			</li>
			<li>
				<a href="/cbx/cms/DE/DE/web/home/guided_tours/guided_tours_mediengestaltung">Mediengestaltung</a>
			</li>
			<li>
				<a href="/cbx/cms/DE/DE/web/home/guided_tours/guided_tours_verkauf">Verkauf</a>
			</li>
		</ul>
	</li>
</ul>
<!-- jQuery Fade-In -->
$(document).ready(function(){
	$(".dropdown").find("li:has(ul)").each(function () {	
		$(this).hover(
			function(){
				$("> ul", this).hide();
				$("> ul", this).css("visibility", "visible");
				$("> ul", this).fadeIn("200");
			},
			function(){
				$("> ul", this).hide();
				$("> ul", this).css("visibility", "hidden");
			}
		);
		
		$(this).click(
			function(){
				$("> ul", this).hide();
				$("> ul", this).css("visibility", "hidden");
			});
		});
});

Comment 1

[aravindm]

Regression Range : 
works: 
Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110105 Firefox/4.0b9pre
broken:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre
pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2bd42931b03&tochange=c6e65b6259db

Comment 2

[Boris Zbarsky [:bzbarsky]]

Perhaps a regression from bug 615794?

Comment 3

[Boris Zbarsky [:bzbarsky]]

In particular, that patch could well have affected hit-testing.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Maybe we shouldn't snap if the display list is for hit-testing?

Comment 5

[Michel Brabants]

Hello,

I confirm this bug in firefox 4.0.1 (Ubuntu Lucid - ppa-packages). I encountered it while creating a new site. I'm developing and testing it at the moment under linux. My menu works fine in Konqueror (linux), chrome (linux and windows) and IE 7, ... (windows). Only firefox causes this problem.

I can publish my code, but you can trigger it with this sample-menu online: http://javascript-array.com/scripts/jquery_simple_drop_down_menu/


I suppose that a lot of sites have this problem as this is commonly-used system to create menu's as far as I know. Because of this, I would classify this bug as important ...

Kind regards,

Michel

Comment 6

[Michel Brabants]

FYI : firefox acts as if the the li-element with class="mainitem" does not contain a small line between the a-element and the dropdownmenu represented by the ul-element with class="sub". When you cross that line, the mouse moves "out" of the li-element with class="mainitem" according to firefox, which isn't happening in the other browsers. It's easier to trigger on certain zoom-levels compared to other zoom-levels as if it were a rounding-error ..., but that is purely a guess.

<li class="mainitem">
  <a>test-menu</test>
  <ul class="sub">
    <li/ class="subitem">
  </ul>
</li>

Michel

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm unable to reproduce on Windows trunk.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Ah, I have to zoom in four levels.

Comment 9

[cwbussard]

Font size seems to have something to do with it. Increasing the font in my menu from 0.7em to 11pt appears to solve the problem.

Comment 10

[j.gonser]

Hi, we have fixed the menue on our site by overlapping the submenue with 1px into the menue bar. But this is not a good solution. So we hope you get the code work in FF4 as it was rendered in FF 3.6. If you need the unfixed version again, please contact me.

Comment 11

[j.gonser]

(In reply to comment #9)
> Font size seems to have something to do with it. Increasing the font in my
> menu from 0.7em to 11pt appears to solve the problem.

Yes, I can confirm this behaviour with our menue, too.

Comment 12

[Michel Brabants]

Thank you for the hint, I solved it the same way. More specifically, I added the following css to the li-tags within the submenu:

position: relative;
top: -1px;

I hope this gets fixed soon, so that I can remove this code, which is only needed for firefox 4.

Michel

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Testcase

Near-minimal standalone testcase. Alerts "FAIL" on my system when it finds a Y-coordinate that hits the body between the two DIVs --- which should not happen.

Comment 14

[j.gonser]

I can confirm this behaviour on my machine, too. In IE, Safari, Chrome and FF 3.6 I get no error. In FF 4.0.1 I get the following message: "FAIL at 40".

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In this testcase we have two elements, one that extends from y=1218 to y=2418 (appunits) and another extending from y=2418 to y=3618 (on my system). nsLayoutUtils::GetFramesForArea is called for y=2400,height=1. The display list contains a display item for the first element, but not the second because the second element's frame overflow area doesn't intersect the hit-test area. But GetBounds() for the first element's display item snaps the display item bounds to the area we'll draw, and the bottom edge snaps to 2400, so it no longer intersects the hit-test area.

Indeed, as Boris guessed from the beginning, the best solution is probably to simply not snap in GetBounds() when hit-testing. I see no real downside to that.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Tiny optimizatoin

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 18

[Timothy Nikkel (:tnikkel)]

(In reply to comment #15)
> Indeed, as Boris guessed from the beginning, the best solution is probably
> to simply not snap in GetBounds() when hit-testing. I see no real downside
> to that.

Except maybe that hit testing would no longer match what we draw on the screen: the cursor could look like it is over something but actually isn't.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It can be off by at most half a device pixel, which I don't think is really an issue since normal people can't point with that accuracy anyway.

I thought of making the hit-test rect one device pixel width and height, but it didn't seem any better and it's a little bit more complicated (and might get confusing with transforms etc).

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(and would not be right for elementFromPoint --- see testcase)

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/projects/cedar/rev/dd66203ac8aa

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oops, forgot the other patch:
http://hg.mozilla.org/projects/cedar/rev/d846d3ba90d0

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bustage fix for test in bug 463104:
http://hg.mozilla.org/projects/cedar/rev/9f727708bed0

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/dd66203ac8aa
http://hg.mozilla.org/mozilla-central/rev/d846d3ba90d0
http://hg.mozilla.org/mozilla-central/rev/9f727708bed0

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 536060 [details] [diff] [review]
fix

Very simple and safe patch, fixes an annoying FF4 regression that affects usability of some DHTML menus

Comment 26

[Johnathan Nightingale [:johnath]]

Comment on attachment 536060 [details] [diff] [review]
fix

Discussed in triage today: we love safe fixes for aurora, but we worry about *any* layout change in beta that isn't tragic in impact. Please re-nom if you think we're overestimating risk or underestimating impact in 5

Comment 27

[Christopher Blizzard (:blizzard)]

Comment on attachment 536060 [details] [diff] [review]
fix

Marking as + for approval-mozilla-beta because of the impact of the library on the web.  This is a popular library.  Please keep an eye on it.  We're late in the beta cycle.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-aurora/rev/e72be6ba64dd

http://hg.mozilla.org/releases/mozilla-beta/rev/05b19f48b9ee

Comment 29

[Martin Bündgens]

I could need some suggestion for this on http://www.animemanga.de/.
I tried anything.. yet, that is still a large issue on 4.0.1.
Anyone with some suggestion ?

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Firefox 5 will be out in a few days. It fixes this issue.

Comment 31

[Martin Bündgens]

Hello Robert, hopefully.. but is there maybe any CSS trick for this ? What is main core for this issue ?

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You could try to make sure that the bottom of the menu bar is aligned on a pixel boundary, by positioning and sizing it using px. However, I don't recommend trying to work around this. Firefox 5 will be out in a few days and people will upgrade to it very fast.