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

[21cdb]

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.

[Jason_JM]

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)

[Jason_JM]

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.

[21cdb]

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 testbp.org 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 (testbp.org) or a user-blog. Excuse me when i'm wrong, but i'm a little bit confused about this behaviour.

[r-a-y]

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.

[r-a-y]

​http://trac.buddypress.org/browser/trunk/bp-core/js/admin-bar.js

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

[Jason_JM]

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

[Jason_JM]

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

Going to pass the ball on this one.

[r-a-y]

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 jQuery.support.boxModel conditional (​http://docs.jquery.com/Utilities/jQuery.support) 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 ;)

[plrk]

​http://www.ie6nomore.com/

[erich73]

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

[Jason_JM]

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

Or

Use the Chrome 'Frame' Plugin for IE. ​http://code.google.com/chrome/chromeframe/

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!

Yay!

[r-a-y]

• 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 jQuery.support.boxModel 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.

[r-a-y]

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.

[apeatling]

Patch breaks second level nav menus.

[r-a-y]

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

[r-a-y]

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.

[erich73]

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

[DJPaul]

Is this still an issue?

[r-a-y]

Let's punt it.

[johnjamesjacoby]

Better yet, let's close it. :)

Reopen if issue resurfaces.

[r-a-y]

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

Sorry!