CUNY Academic Commons

OP here. It's strange because it's happened several times to me in the past, but checking it today, the menus are much more stable when I hover over links (even when moving rapidly).

I am experiencing this problem consistently. For me the dropdown menus from the upper user-menu-bar disappear after I move my mouse down the dropdown menu far enough that I am over the lower site-navbar. It is very consistent, and is disruptive: it is preventing me from logging out, for example.

I have observed this problem in the classroom computer at the GC which is running windoze 7/IE, and on my laptop running Ubuntu/FFX 3.6.11.

and Boone, re: the idea that it is a page load issue, I get the bug consistently, and regardless of how long the page has been open, or if I hover/wait over the dropdown to wait for any subsequent assets to load.

seems more likely that it is just a case of the all-too-treacherous CSS dropdown cross browser compatibility game.

Just to add, I am now on OSX/FFX 3.6.3 and the bug is not present.

I've verified the bug on Ubuntu + Firefox 3.6.x. I'll have a closer look.

I've had a little time to look at this but not enough time to work out a solution. I think the basic idea for a solution is to add some padding to some of the ULs and make bigger hit areas for the menus. See this page as an example
http://www.positioniseverything.net/css-dropdowns-red.html

In terms of implementing part of the problem is that the current CSS seems very complex for these drop downs and so it will take a minute for me to understand that and be able to integrate a solution like in the link above with the current css.

Thanks for taking a look, Chris. The complexity of the CSS is the price you pay for non-JS hover/dropdown menus.

You might be right that the size of the UL elements is part of the issue, but I have some doubts. The dropdown always disappears at the same vertical point on the page, where the next div starts. That makes me think it's a positioning or z-index thing. (Sadly, as those issues vex me to no end.)

You may be right about the zindex or positioning thing. CSS drop downs can be a bit complex but I don't think they need to be as complex as we have. I could be wrong. It looks like we're using the Suckerfish or Son of Suckerfish technique I may run some tests on a separarate page outside of the commons and test some things.

Cool, thanks. Don't feel like you have to rewrite the whole menus, though. These are based on the BP menus, which are fairly widely tested. I'd bet that the problem is with our implementation rather than the menus themselves.

FWIW BP menus will be revamped soon to take advantage of some new WP features, so for now we just really need a stopgap.

I've been playing with this for the last hour and the prognosis isn't good. After a bit of experimentation, it seems like the problem isn't related to the markup or the style, but to the rendering speed on the machine. FF, on my slowish netbook, takes a noticeable fraction of a second to recognize the hover event on the admin bar. I'm pretty sure that this is what's causing the problem on the inner menus: that split second is enough time for the hover to be lost on the parent element, so that the menu ends up collapsing.

The lag doesn't exist on other (faster) machines. It also goes away when I switch to Chrome on my netbook, which suggests that Chrome is a faster renderer than FF (something I guess I already knew).

I don't have any bright ideas about how to fix the problem. On a lark, I deleted all of our custom styles on cdev for a moment to see if FF was being crushed under the sheer weight of all the CSS. No help. I'm guessing the problem is the application of hover pseudo-classes and the rerendering of large amounts of markup, which will become worse in cases where users are members of more groups/blogs and thus have more menu content.

Any ideas?

Boone, I started looking at the borders of things and have another idea about the problem. I noticed that in FF Win the problem seemed to occur when your mouse is right at the border of two items in the list. Right now the ul for the list is only 28px high. This is a leftover from a style for the main UL that has the top level nav. The drop downs don't need the height set like that but they all have a 28px height inherited.

So in Firebug I added this style in admin-bar.css to the styles already in the #wp-admin-bar ul li ul selector
#wp-admin-bar ul li ul{
/*other styles here */
height:auto !important;
}

and that seemed to make things a lot better. The ul then stretches to cover the li's inside of it. I don't have VMWare installed on my mac and my mac at least doesn't have the problem to begin with so I couldn't test it with the actual change to admin-bar.css. I made that change, and also changed the background color to black so that if it shows through it would blend in, and pushed them to the git master.

Boone, can you pull that (or just make the change to your files) and test it to see if you see the change too?

Chris

Go, Chris!