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
In particular, that patch could well have affected hit-testing.
Maybe we shouldn't snap if the display list is for hit-testing?
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)
8 years ago
Assignee: nobody → roc
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.
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.
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.
(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.
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
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.
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.
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+
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: 8 years ago
Resolution: --- → FIXED
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 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 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+
8 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.
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.