Expand Appbar menu on hover

I've been thinking about adding this option for awhile. It'll get in sooner or later.

IceCreamYou and d0t101101:

I provided a patch that adds this functionality for menu items and any other blocks except for the "Alerts" block. The patch adds an additional setting to the Appbar settings page (admin/settings/appbar). I left the default at "open on click", so you need to change this setting to "Open appbar blocks on hover" to see the changes. The patch needs to be applied from the appbar module directory itself.

I haven't changed the functionality for the "Alerts" block yet, as this block functions differently. It's the only block in the appbar that has an icon in the appbar to open and close instead of the "minimize" link at the top of the opened window.

IceCreamYou: What do you think about creating a standard way for closing appbar blocks instead of having two different feature sets?

Looking forward to your feedback!

Attached is a patch that implements this feature more cleanly.

The differences from a functional perspective include:

• The patch in #2 simply opens a block on mouseover but does not close it on mouseout; this patch opens the block on mouseenter and closes it on mouseleave.
• The patch in #2 allows EITHER open-on-click OR open-on-hover; this patch makes the setting block-specific, so BOTH hover and click blocks can exist on the same bar. (This patch also doesn't require another admin setting.)

From a code perspective, the implementations are substantially different.

@haagendazs: Since you submitted this patch by my request as part of your effort to become a co-maintainer, I will respond to it via email.

@d0t101101: Please test this patch. If it works, set this issue to RTBC and I will commit it as soon as I can.

I have 4 Core i7 processors @ 2.67GHz and I'm using FF3.6.10, so I wouldn't notice any performance hit -- but that animation is only 200ms and it's pretty standard and fast. I wouldn't expect any slowdown unless you're running IE6 on WinXP on old hardware.

When you quickly move your mouse over/off any hover item anywhere on the internet that has an animation, it will open and close repeatedly for awhile. This is how it's supposed to behave. It executes the open/close code every time you hover on/off, so if you hover on/off lots of times, it will execute that code lots of times.

There is a jQuery plugin called hoverIntent that basically adds a pause before executing hover actions. If you want you can override the JS in Appbar to use that instead. Actually, I will add support for it before I commit the patch but I won't add it as a dependency. (You will need the plugin loaded on your site for this to work -- there is a module that is supposed to do that.)

Adding an option to select the animation is overkill. 99.9% of people will never use it, and more people will be confused by it than will find it useful. Having no animation looks crappy, and it's surprising when stuff suddenly appears; animation makes it clear what happened and why. And the current animation can be overridden just as easily as no animation.

Honestly, IMHO the hover thing is pretty obnoxious, and you should expect all of the usual minor problems if you choose to use it (the two main ones being performance in older browsers and weird behavior when you move the mouse around quickly). If you expect your users to be moving their mouse quickly across the bottom of the screen and you don't like it that a bunch of stuff pops open when that happens, you might want to think harder about why you're really using the hover state. And 9 hover blocks might be a little excessive.

Hmm, very strange that you would have performance problems then. Interesting. Will have to investigate that further at some point then.

Interesting that you point out mobile as well -- AFAIK the hover state doesn't exist on most mobile browsers.

I'm sure others will appreciate sharing your overrides. :-)

Marking this issue for testing - I'd be interested in this, as long as it's a configurable option :)

Committed to dev. Let me know if you have any serious problems. Thanks for the help

I'm seeing a huge performance hit on some pages post upgrade from Sep dev to latest dev. MBP like a year old. Performance issue seems to occur on long pages and only on the animation of the menu sliding open or closed.

I mean, if you switched your blocks to hovering it's going to seem a little slower because the show/hide behavior is going to happen more often. This is the only relevant JS difference. You can try using the older version and see if it makes any difference, but the sliding motion was actually using the same effect; the only difference was that the "hover" setting wasn't supported. I've also attached a version that uses toggle() instead of slideToggle() and hide() instead of slideDown(). IMO that's a usability sacrifice but it might be marginally faster.

Also, browser and browser version are important for things like this...

wasn't using Hover.

To help with page load somewhat I was able to do the following though --

If you kill off this function --

$('.appbar-block-popup,.appbar-block-hover').each(function(index) {
//The -1 is a cheap hack to make this look better when the border is 1px.
var leftPos = $(this).offset().left - 1;
$(this).find('.appbar-block-content').css('left', leftPos);
});

and instead do absolute positioning in place of fixed, the click to pop-up blocks will still display in the correct location and will work correctly when resizing the browser window after page-load

here's my css for my appbar-block-content

.appbar-block-popup .appbar-block-content {
background-color: #FFFFFF;
border: 1px #B5B5B5 solid;
bottom: 25px;
display: none;
margin-bottom: 0px !important;
margin-left: -1px;
max-height: 450px !important;
min-height: 25px !important;
overflow-x: hidden;
overflow-y: auto;
position: absolute;
margin-right:0px;
padding:0px;
width:135px !important;
z-index: 51;
}

That code runs once. It would not be slowing your page down.

well, it loads faster on initial render