Conflict with WP admin bar

[dariodev]

Hi Joel,
I've been using Superfish for years and I'm happy to see that you are continuing to update the plugin.
There is compatibility issue with WordPress admin-bar (wp-includes/js/admin-bar.min.js?ver=3.5.1). When the user is logged in (and/or the admin bar is turned on), menus are not opening on mouseover. Menus are opening only on mouse click (but not behave as intended) , even if "useClick" is set to false. Only if "useClick" is true, then menus are working good. And again, if WP admin bar is off, everything (useClick false/true) works great.

[joeldbirch]

Hi,

Great to hear from a die-hard Superfish fan :)

I've tried to reproduce this issue but it works fine for me. I use WordPress daily and haven't seen the issue. I wonder if it still happens for you if you change the theme? Can you try that please? It would be good to figure out what is causing the issue and fix it if it does turn out to be an issue with Superfish.

Cheers
Joel.

[dariodev]

:)
Yes, I've tried with twentytwelve, with all plugins turned off. I've tried again on clean WP installation - WP 3.5.1, Twentytwelve. I just made screen-cast with annotations: http://youtu.be/6roe8wGiY00 This screencast is made in Chrome, but issue is same in all browsers.

[joeldbirch]

Amazing work. Your screencast really removed any question of there being a problem, I really appreciate the effort!

I began to replicate the same environment you have in the screencast, and half way there it dawned on me. Superfish uses the hoverIntent plugin if it detects its availability on the page. However, because Superfish now uses event delegation, it requires a patched version of hoverIntent. Wordpress includes the official (unpatched) hoverIntent plugin for use in the admin bar, so Superfish is using that and failing. You should see an error displayed in the JavaScript console explaining the problem.

This explains why only the hover events are affected and not the click events used with the useClick feature. The reason why I've never seen the problem in my own projects is because I've preempt it, apply a fix and (stupidly) not given a thought to how it would also be affecting other people. See below for solutions.

Quick fixes:

• If you don't intend Superfish to use hoverIntent, simply set its disableHI option to true upon initialisation, or
• If you do intend Superfish to use hoverIntent, you need to deregister WordPress' version and point to a patched version. The patch is backward compatible, so WordPress won't care that it is using the updated version. Here is the code I use in my functions.php file:

wp_deregister_script('hoverIntent');
wp_register_script('hoverIntent', ( '/path/to/hoverIntent.js'), array('jquery'), 'r6.1');

More thorough solutions:
I'll have a think about what I should do to save other people from encountering this conflict. I think the easiest solution would be to for me to set the default for disableHI in the next release to true so people have to opt-in to it, but I'd prefer to avoid doing this. Or maybe I'll ask Brian Cherne to update his official hoverIntent plugin to include the event delegation patch. I guess I then need to get WordPress to include that updated version in their next release, somehow. This would be the ideal—but not instant—resolution.

Thanks so much for bringing this to my attention. Please let me know if this fixes the issue for you.

Cheers
Joel.

[joeldbirch]

I have commented about this on an existing pull request over on Brian Cherne's repo.

[dariodev]

All right, it works! You rock, thank you very much. About possible solutions. I'm for disableHI to true for the next release (temporarily?), this could save a lot of headache for someone. The ideal solution involves a lot of variables, so yes I guess it's far from an instant :)
Thank you so much for your quick response and quick fixes.

[joeldbirch]

Brian Cherne has now updated his plugin to support event delegation! We just need to get WordPress to update to the new version. Not sure how to go about this, but I'll have a look around…

[joeldbirch]

I have created a WordPress Trac ticket with the update request.

[RollYourOwnEd]

Hey guys, I had exactly the same problem and this helped me! Thanks to both of you!

[ruudbwai]

yeah also had this issue, almost cried :/ didn't know hoverintent was bundled in with wordpress

[ElricE]

Got a curly one for you, as I've found this behaviour is still happening in our WP site. When disableHI is set to "true", the hoverClass correctly appends to the LI elements with child menu elements. However, when disableHI is set to "false", the hoverClass is instead appending to the top level UL. Menus expand on right-click but not on hover as a result of the hoverClass appending incorrectly.

Now hoverIntent has been upgraded so no dramas there, and I've tried disabling all non-essential javascript hoping to find a conflict but no luck. I also dropped in a duplicate of the "basic" menu provided in the plug-in's example folder to see if it was an issue with the menu itself, but got exactly the same result.

Now I have been able to patch in a temp work around. I changed line 60 from

$menu.hoverIntent(over, out, targets);

to

$('li:has(ul)').hoverIntent(over, out, target); 

which seems to work for now but, but not being the most adept at JS am not sure whether it the best option. Could the hoverIntent events be bound using

.on

as the variables in the next section

$menu.on('mouseenter.superfish', targets, over).on('mouseleave.superfish', targets, out);

works without a hitch.

To be quite frank this has had me stumped for days

[joeldbirch]

Curly indeed! Are you able to provide a link so I can see the problem in action? I'd be happy to look into it but I need to be able to reproduce it, somehow. Thanks.