Skip to:

Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#1021 closed defect (bug) (worksforme)

Slow mouse-over events when using the Buddy-Bar [Has Patch]

Reported by: 21cdb's profile 21cdb Owned by: apeatling's profile apeatling
Milestone: 1.5 Priority: trivial
Severity: Version:
Component: Core Keywords: Buddy-Bar, Slow, has-patch
Cc: Jason_JM


The mouse-over at the Buddy-Bar (navigation header) behaving very slow, especially on older hardware. It takes a few seconds to move from "Log In" to "Sign Up" when moving with the mouse. This is only the case on the mainblog, not on the user-blogs.

Attachments (1)

admin-bar(v1).patch (1019 bytes) - added by r-a-y 15 years ago.
Removed last line in old patch that was causing the error in IE6

Download all attachments as: .zip

Change History (25)

#1 @Jason_JM
15 years ago

  • Cc Jason_JM added
  • Keywords Buddy-Bar Slow added
  • Priority changed from major to trivial
  • Resolution set to wontfix
  • Status changed from new to closed
  • Summary changed from Slow mouse-over at the Buddy-Bar to Slow mouse-over at the Buddy-Bar.

The admin-bar uses pure css hover pseudo classes.

The admin-bar display interaction speed is dependent on the browsers internal implementation of css/html pseudo classes, it's implementation of the OS's native UI libraries, and overall machine power. All of which outside the power of the devs here coding BuddyPress.

Please try a faster browser, this may help you. I recommend Chrome. Below is an ordered (fastest to slowest) list of css/html pseudo parser speeds by browser:

  1. Chrome 3 (nightly build)
  2. Safari (nightly build)
  3. Firefox 3.5 (nightly build)
  4. Opera (nightly build)

#2 @Jason_JM
15 years ago

  • Type changed from defect to enhancement

Just a note, older browsers have slower html selector implementations. For instance, IE6 will slow down considerably even when the entire contents are in memory. This is purely because it's algorithm for selecting/sorting a large element list is inefficient.

I would re-open this and be happy to look at it if you could duplicate this on other browsers, and instead make it an 'enhancement' as it does not impede on actual functionality.

#3 @21cdb
15 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

The thing is, i'm using a brand new MacBook Pro with latest version of Safari and Firefox and everything is perfect! On work we have some old pentium 4 PC's running IE7 and Firefox 3.5.

On all of these PC's the main-blogs buddy-bar behaves slow. I checked it on on several PC'S. The wired thing is that the buddy-bar behaves snappy on the user-blogs on the same PC's! How could this be explained with algorithm for selecting/sorting? If that would be the case for the slow buddybar on these PC's than it should be no matter if i'm browsing the main-blog ( or a user-blog. Excuse me when i'm wrong, but i'm a little bit confused about this behaviour.

#4 @Jason_JM
15 years ago

  • Owner set to Jason_JM
  • Status changed from reopened to accepted

#5 @r-a-y
15 years ago

I haven't looked into this but I know that the menu's use the Suckerfish javascript method so older browsers like IE6 will show the mouseover menu.

That could be the root of the problem.

21cdb, try disabling javascript and see if the mouseover menu slowness goes away.

#6 @r-a-y
15 years ago

Why not use jQuery's hover() function, instead of having to use two different functions (mouseout, mouseover) to achieve the same end?

#7 @Jason_JM
15 years ago

  • Summary changed from Slow mouse-over at the Buddy-Bar. to Slow mouse-over events when using the Buddy-Bar.

I thought suckerfish had pretty good fallback support, and uses the pseudo classes I mentioned.

I second r-a-y's notion. The only negative is a greater reliance on jQuery.

It may be in our best interest to use jQuery now but port everything over to newer html5/css3 keys as they could accomplish somewhat the same. Just a thought.

In the end however, the least resistive change is to not use IE6. You've got to cut it loose sometime...

#8 @Jason_JM
15 years ago

  • Owner changed from Jason_JM to apeatling
  • Status changed from accepted to assigned

Andy said he'd be looking into this from the forum thread.

Going to pass the ball on this one.

#9 @r-a-y
15 years ago

Suckerfish is good, but the method adopted here is a jQuery variation of it.
Also the JS will fire every time regardless...

One way to get around it is to detect only IE6 and then apply the addClass/removeClass.

Could use a conditional ( to do it.


I wouldn't go with CSS3 just yet... some people still use older versions of certain browsers just yet (eg. FF2).

Although I wouldn't mind cutting off IE6 completely, then we wouldn't even have to worry about this ticket in the first place ;)

#11 @erich73
15 years ago

I just have made this test as per your suggestion (I am using FireFox-browser version 3.0.14):

  • I have just disabled JavaScript at my browser and the mouse-over became working perfectly fine and fast..
  • Then I have re-activated JavaScript and the mouse-over got very slow again.

So it is absolutely clear for me: the issue is coming from the JavaScript.....

#12 @Jason_JM
15 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

User has reported in original forum thread that the latest FireFox Version 3.x (as of this message) works with no slowdown.

For IE6, IE7, IE8, you guys can switch to FireFox, Safari, Chrome...


Use the Chrome 'Frame' Plugin for IE.

About the jQuery enhancements, R-A-Y can you create a new enhancement ticket and hook us up with a patch? I know you can make them now. :-D

Closing this ticket!


#13 @r-a-y
15 years ago

  • Keywords has-patch added
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Summary changed from Slow mouse-over events when using the Buddy-Bar. to Slow mouse-over events when using the Buddy-Bar [Has Patch]
  • Added an IE6 conditional around the Suckerfish classes
  • Checks if browser supports the CSS max-height attribute; IE6 is the only modern browser that doesn't support max-height (Thickbox also uses this technique to check IE6)
  • Replaced mouseover() and mouseout() with jQuery.hover()
  • Did not use since IE6 and IE7 will return false; only wanted to target IE6
  • jQuery.browser is deprecated in jQuery 1.3 so I didn't use that

I decided to post the patch in this ticket rather than create a new one, since the issue is related to this patch. Feel free to split the ticket though.

Tested on IE6 and IE7. IE7 uses CSS2 :hover selector instead of Suckerfish.
Please test.

#14 @r-a-y
15 years ago

Ignore the newline at the end of the patch!

Also change the selector back to

#wp-admin-bar ul.main-nav li

if you want.

#15 @apeatling
15 years ago

  • Type changed from enhancement to defect

#16 @apeatling
15 years ago

Patch breaks second level nav menus.

#17 @apeatling
15 years ago

  • Milestone changed from 1.1 to 1.2

15 years ago

Removed last line in old patch that was causing the error in IE6

#18 @r-a-y
15 years ago

Updated patch should work.

The first patch added a stupid new line string to the end of the patch (blame WinMerge!).

I've removed it and tested it on IE6; it works now.

Also tested on IE7 for sanity.

#19 @apeatling
14 years ago

  • Milestone changed from 1.2 to 1.2.1

#20 @erich73
14 years ago

I do not see this issue any longer (no issue like this in BP1.2).
I guess this ticket could be closed ?

#21 @DJPaul
14 years ago

  • Component set to Core

Is this still an issue?

#22 @r-a-y
14 years ago

Let's punt it.

#23 @johnjamesjacoby
14 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

Better yet, let's close it. :)

Reopen if issue resurfaces.

#24 @r-a-y
14 years ago

By "punt", I meant "close" ;)


Note: See TracTickets for help on using tickets.