Last Comment Bug 646757 - List item in css-drop down menu losing hover when moving in nested list (sub menu)
: List item in css-drop down menu losing hover when moving in nested list (sub ...
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Layout: Floats (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 2 votes (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
:
Mentors:
http://www.crossbase.de
Depends on:
Blocks: 615794 646037 663680
  Show dependency treegraph
 
Reported: 2011-03-30 23:35 PDT by j.gonser
Modified: 2011-06-19 15:59 PDT (History)
10 users (show)
roc: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed


Attachments
Testcase (598 bytes, text/html)
2011-05-30 04:31 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
Tiny optimizatoin (802 bytes, patch)
2011-05-30 05:32 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
tnikkel: review+
Details | Diff | Review
fix (3.26 KB, patch)
2011-05-30 05:33 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
tnikkel: review+
bugzilla: approval‑mozilla‑aurora+
blizzard: approval‑mozilla‑beta+
Details | Diff | Review

Description j.gonser 2011-03-30 23:35:07 PDT
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 2011-03-31 02:59:53 PDT
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 [:bz] (Out June 25-July 6) 2011-03-31 07:23:01 PDT
Perhaps a regression from bug 615794?
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-03-31 07:23:17 PDT
In particular, that patch could well have affected hit-testing.
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-03-31 07:24:11 PDT
Maybe we shouldn't snap if the display list is for hit-testing?
Comment 5 Michel Brabants 2011-05-25 15:46:15 PDT
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 2011-05-25 15:55:49 PDT
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) (Exited; email my personal email if necessary) 2011-05-25 20:28:58 PDT
I'm unable to reproduce on Windows trunk.
Comment 8 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-25 20:32:17 PDT
Ah, I have to zoom in four levels.
Comment 9 cwbussard 2011-05-25 23:29:15 PDT
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 2011-05-27 04:17:29 PDT
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 2011-05-27 04:19:23 PDT
(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 2011-05-28 03:51:34 PDT
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) (Exited; email my personal email if necessary) 2011-05-30 04:31:40 PDT
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.
Comment 14 j.gonser 2011-05-30 04:37:12 PDT
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) (Exited; email my personal email if necessary) 2011-05-30 05:06:55 PDT
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) (Exited; email my personal email if necessary) 2011-05-30 05:32:35 PDT
Created attachment 536059 [details] [diff] [review]
Tiny optimizatoin
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-30 05:33:01 PDT
Created attachment 536060 [details] [diff] [review]
fix
Comment 18 Timothy Nikkel (:tnikkel) 2011-05-30 11:18:48 PDT
(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) (Exited; email my personal email if necessary) 2011-05-30 13:36:23 PDT
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) (Exited; email my personal email if necessary) 2011-05-30 13:36:52 PDT
(and would not be right for elementFromPoint --- see testcase)
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-30 14:55:59 PDT
http://hg.mozilla.org/projects/cedar/rev/dd66203ac8aa
Comment 22 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-30 16:25:54 PDT
Oops, forgot the other patch:
http://hg.mozilla.org/projects/cedar/rev/d846d3ba90d0
Comment 23 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-30 17:28:34 PDT
Bustage fix for test in bug 463104:
http://hg.mozilla.org/projects/cedar/rev/9f727708bed0
Comment 25 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-31 04:05:19 PDT
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] 2011-06-01 11:40:53 PDT
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) 2011-06-01 12:18:00 PDT
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) (Exited; email my personal email if necessary) 2011-06-01 17:31:44 PDT
http://hg.mozilla.org/releases/mozilla-aurora/rev/e72be6ba64dd

http://hg.mozilla.org/releases/mozilla-beta/rev/05b19f48b9ee
Comment 29 Martin Bündgens 2011-06-19 10:30:39 PDT
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) (Exited; email my personal email if necessary) 2011-06-19 15:36:49 PDT
Firefox 5 will be out in a few days. It fixes this issue.
Comment 31 Martin Bündgens 2011-06-19 15:55:58 PDT
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) (Exited; email my personal email if necessary) 2011-06-19 15:59:59 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.