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

RESOLVED FIXED

Status

()

Core
Layout: Floats
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: j.gonser, Assigned: roc)

Tracking

({regression})

Trunk
x86
Windows 7
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox5 fixed, firefox6 fixed)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

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

6 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Perhaps a regression from bug 615794?
Blocks: 615794
In particular, that patch could well have affected hit-testing.
Maybe we shouldn't snap if the display list is for hit-testing?
Blocks: 646037
Summary: List item in css-drop down menue loosing hover when moving in nested list (sub menue) → List item in css-drop down menu losing hover when moving in nested list (sub menu)
Assignee: nobody → roc
Keywords: regression
Version: unspecified → Trunk

Comment 5

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

6 years ago
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
I'm unable to reproduce on Windows trunk.
Ah, I have to zoom in four levels.

Comment 9

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

Comment 10

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

Comment 11

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

6 years ago
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
Created attachment 536048 [details]
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.
(Reporter)

Comment 14

6 years ago
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".
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.
Created attachment 536059 [details] [diff] [review]
Tiny optimizatoin
Attachment #536059 - Flags: review?(tnikkel)
Created attachment 536060 [details] [diff] [review]
fix
Attachment #536060 - Flags: review?(tnikkel)
Attachment #536059 - Flags: review?(tnikkel) → review+
(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.
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).
(and would not be right for elementFromPoint --- see testcase)
Attachment #536060 - Flags: review?(tnikkel) → review+
http://hg.mozilla.org/projects/cedar/rev/dd66203ac8aa
Whiteboard: [fixed-in-cedar]
Oops, forgot the other patch:
http://hg.mozilla.org/projects/cedar/rev/d846d3ba90d0
Bustage fix for test in bug 463104:
http://hg.mozilla.org/projects/cedar/rev/9f727708bed0
http://hg.mozilla.org/mozilla-central/rev/dd66203ac8aa
http://hg.mozilla.org/mozilla-central/rev/d846d3ba90d0
http://hg.mozilla.org/mozilla-central/rev/9f727708bed0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
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
Attachment #536060 - Flags: approval-mozilla-beta?
Attachment #536060 - Flags: approval-mozilla-aurora?
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
Attachment #536060 - Flags: approval-mozilla-beta?
Attachment #536060 - Flags: approval-mozilla-beta-
Attachment #536060 - Flags: approval-mozilla-aurora?
Attachment #536060 - Flags: approval-mozilla-aurora+
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.
Attachment #536060 - Flags: approval-mozilla-beta- → approval-mozilla-beta+
http://hg.mozilla.org/releases/mozilla-aurora/rev/e72be6ba64dd

http://hg.mozilla.org/releases/mozilla-beta/rev/05b19f48b9ee
status-firefox5: --- → fixed
status-firefox6: --- → fixed
Blocks: 663680

Comment 29

6 years ago
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 ?
Firefox 5 will be out in a few days. It fixes this issue.

Comment 31

6 years ago
Hello Robert, hopefully.. but is there maybe any CSS trick for this ? What is main core for this issue ?
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.
You need to log in before you can comment on or make changes to this bug.