Project

General

Profile

Bug #340

BP Admin Bar Menu Mouseover Areas Too Sensitive

Added by Matt Gold about 11 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority name:
High
Assignee:
Category name:
BuddyPress (misc)
Target version:
Start date:
2010-09-16
Due date:
% Done:

0%

Estimated time:

Description

A report from UserVoice:https://cunycommons.uservoice.com/admin/forums/35103-general/suggestions/1060455-dropdown-menus-are-too-sensitive-on-mouseover

Hello, I keep noticing a bug where the dropdown menus on the front page are very sensitive and often collapse when trying to click on an item. If I hover my mouse or move it too quickly (and by "too quickly", I mean average speed), the menus close. Sometimes I have to key down using my keyboard just to reach a menu item. This occurs in Firefox 3.6.8

I don't seem to have this problem myself, but I've encountered it a few times and I've seen others run into it. I know that we dealt with this a long time ago; the ticket might be in Basecamp.


Related issues

Related to CUNY Academic Commons - Bug #255: Unable to scroll through list of GroupsDuplicate2010-05-26

History

#1 Updated by Shawn M about 11 years ago

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).

#2 Updated by Boone Gorges almost 11 years ago

  • Status changed from Assigned to Reporter Feedback

I tried reproducing with all the browsers I've got (including FF 3.6.x) and I haven't been able to reproduce it.

Shawn - When you had the problem, did it generally persist across an entire session? Or was it usually just an isolated problem, on a single page, that went away when you clicked to another page? I'm guessing (totally off the top of my head) that the problem is on the client end - that the browser is being slow at loading some Javascript or additional styles or something that are causing the browser's CSS renderer to hiccup. If the problem is intermittent, it'd lend credence to this theory. And if that's the problem, the best we can do is to speed up the way that our page loads, which is kind of an ongoing project!

#3 Updated by Michael Mandiberg almost 11 years ago

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.

#4 Updated by Michael Mandiberg almost 11 years ago

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

#5 Updated by Boone Gorges almost 11 years ago

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

#6 Updated by Boone Gorges almost 11 years ago

  • Priority name changed from Normal to High
  • Target version set to 1.1

#7 Updated by Boone Gorges almost 11 years ago

  • Status changed from Reporter Feedback to Assigned

Chris - I'm adding you to this ticket on the off chance you'll have a chance to look at it in the next couple days. In my view this is the most important 1.1 ticket that is still open.

#8 Updated by Chris Stein almost 11 years ago

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.

#9 Updated by Boone Gorges almost 11 years ago

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.)

#10 Updated by Chris Stein almost 11 years ago

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.

#11 Updated by Boone Gorges almost 11 years ago

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.

#12 Updated by Boone Gorges almost 11 years ago

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?

#13 Updated by Chris Stein almost 11 years ago

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

#14 Updated by Boone Gorges almost 11 years ago

  • Status changed from Assigned to Resolved

Wow, Chris, that seems to have solved the problem. Awesome job.

#15 Updated by Matt Gold almost 11 years ago

Go, Chris!

Also available in: Atom PDF