Add support to detect hover intent (no dependencies added)

I don't see a usability problem with the current hover behavior. However, if someone steps up to implement and test this, I'll be happy to review any patches posted here. Please assign this issue to yourself, if you are working on a implementation.

If no one works on this issue until April 1st, I'll mark this issue won't fix.

The hoverintent is great. Maybe it is easy to implement.
But since admin_menu is rather thin and at the very top of the page, I feel it is not really needed. Your hardly ever cross that area unvoluntarily. What would be more interesting is to find a way to keep the nested menus easier accessible - I miss them very often trying to press. Maybe a similar script could help, making it stay for one or two seconds, so you get a second try?

@eigentor: If you mean mouseout delays, that has been added to Admin Menu 5.x-2.2, released on 2007-01-08.

hoverIntent would be definitely cool.
Moving the mouse from the browser's viewport to the buttons or location bar hovers the admin_menu bar and thus shows a menu, which can be a real (although not major) annoyance.
AAMOF, I'd say admin menu is a perfect use case for hoverIntent.

However, supporting hoverIntent is probably a snap for js-based menu, but I think admin_menu is currently css-based (:hover), and only uses js for IE6...
Hmm. Wasn't there a discussion about Suckefish menus ? :-)

Better title.

I love this module and use it constantly, but would like add my vote for a short delay before a mouse-over activates the dropdowns. I find it more than distracting - the drop-downs are often in the way of something I'm trying to get to on the page.

HoverIntent is beautiful!

Brushing the cursor over the menu should no longer drop the menu down, yet when you move the cursor to one of the menu items it will drop down seemingly instantly. I've only tested the patch with Firefox 3 on Ubuntu, so other tests are welcome.

This patch uses the minified hoverIntent.

The patch was actually created against 6.x-1.1, I'll see if I can get up a 6.x-dev version shortly.

Glad to see progress here. :)

However, please use an uncompressed version of hoverintent for now. Compression as well as minifying is generally left up to site maintainers who need to optimize performance.

Updated patch against 6.x-dev with uncompressed hoverIntent.js.

Woops, in a rush...

Nice work. Patch works on FF3, IE7 and Google Chrome on XP. Opera is a bit intermittent, but I don't think this is anything admin menu can fix. Looks more like an issue with the plugin. Bit more testing, and this might be RTBC.

Thanks. I just noticed that the menu will always pop up the first time you hover over it after a refresh, I think it may be due to a conflict of interest with the existing JS.

Found a fix with the help of cdale.

It turns out the CSS hover state was being triggered before the JavaScript had a chance to take effect. To get arround this we've used JS to add a new class so we can override the CSS hover state with #admin-menu li.hoverintent:hover > ul, this still allows the menu to drop down with or without JS enabled.

Tested in Fx 3, IE6, IE7 and Opera. It works exactly the same across the board.

This is a huge step forward. A shame Superfish (which had support for this & more built in) couldn't have been used earlier (http://drupal.org/node/132981).

Which version of jQuery does this require? Does it work with a stock Drupal 5?

Erm. For whatever reason I do not see a difference after applying this patch (in Firefox 3 on Windows, that is). Of course I cleared all caches and stuff. No matter at which speed I'm moving over the admin menu, the menu item is hovered/displayed.

Fixed case in CSS comment. (minor)

Yes, yes, even checked both.

Note that the drop downs don't appear in Firefox 3.1 nightlies.

Hm. Firefox 3.0.3. I'll give it another shot.

Sun, D5 or D6?

I don't think jQuery 1.0.4 would be up to the task.

A big +1.

I have tested this on Drupal 5 and it works really well! (You need jquery_update 2 and backport admin_menu.js.)

This makes the admin menus work much more like menus in the OS. That is, a lot more clever and with a lot less frustration.

To select a sub menu item now in Admin menu you must carefully drag the mouse first to the left and the down. With this patch you can drag diagonally, the shortest way. Instead of constantly missing my target, it just works!

The Admin menu is so incredibly useful it more than deserves this kind of attention to user experience details.

> Did you mean Drupal 6? I'm surprised that the patch even applies to D5.

Yes, Drupal 5. I of course needed to apply the code from the patch manually. As I mentioned you need jquery_update version 2 and you need to backport admin_menu.js from Drupal 6.

Thank you very much for the patch. This is a great usability improvement.

Unfortunately, not yet, but I'll try again. This patch needs to be re-rolled against latest 6.x-3.x.

Bevan, see my comment above at http://drupal.org/node/220100#comment-1116838

With your patch, hoverintent will not initiate the first time you hover the menu. You can test this by reloading the page and sweeping your mouse from left to right along the menu. The first time you do this the menu will drop down as if hoverintent wasn't there, however on the second attempt hoverintent will take effect.

#16 provides a solution to this problem.

Hm. What makes you believe that admin_menu no longer supports pure-CSS rendering without JS? That should (and must) still work. If it does not, then we need to fix it (in a separate issue) - however, it worked in my recent tests.

In general, I'm a bit concerned about the amount of JS we are adding/loading for admin_menu, especially in context to other desirable features for 3.x.
So - since this actually requires (more or less) a one-line change only, next to loading an additional JavaScript file, I wonder whether we could simply make this feature depend on http://drupal.org/project/hoverintent being installed? Note, just a thought.

It would be great to get this in. I know Sun doesn't consider that there is a usability problem at the moment, but I think adding hoverintent support would be massive improvement.

This is an improvement for any flyout menu, I've read an article on usability that welcomes couple hundred ms wait on hover.

Personally I find the instant flyout very annoying, usually the menu flies out when I'm trying to switch tabs in Firefox. I have a lot of modules installed so the settings menu is very long, that one is particularly disruptive, you can't ignore when something so big unexpectedly flashes before you (my mind is on the next tab already but flashing forces me to divert attention.)

When might this get included?

Tested the latest patch in IE6, IE7, IE8 and the latest version of Firefox and Opera - it works correctly for each browser.

Subscribe. This would be nice.

It works correctly on Mac OS X (Firefox & Safari).

Hmmm.... Tried to reach someone of you in IRC.

I was about to commit this, but then tested... I think we want to apply hoverIntent to the (first) top-level items only? At least in my testing, I had to "wait" for second- and third-level menus to appear?

I vote for the first level only ;)

Yes - that delay on the second level items is not nice!

At the risk of confusing things, a script at http://blog.threedubmedia.com/2008/08/eventspecialhover.html (that HoverIntent's author Brian Cherne has mentioned himself recently) works better than HoverIntent; also because it measures average speed, the delay it introduces on the second level items is very natural - better than no delay, and better than the current HoverIntent delay.

Could we think of using this instead of HoverIntent?

+1 for eventspecialhover from me too.

Here is a patch for eventspecialhover - hopefully it will apply okay - let me know if it doesn't work for you.

Remember you can alter the parameters of eventspecialhover if you don't like it's current behaviour. I'm happy too though for either to get in. If you prefer hoverIntent Bevan, why not do a patch for it that fixes the 2nd level issue?

This alternative patch does what hoverIntent does without requiring another plugin. It is set to shorter timers than hoverIntent uses by default. For my feeling, a short timer is fine; mostly the problem (to me) is having the menu come up when the mouse swipes over it, but if it stays there for even a few milliseconds it should open. I set it to 100. I played with it at 75, too, and I kind of like it, but the difference is pretty minimal.

This also reduces the hover out delay to 300ms; 400ms felt excessive to me.

Oooh, that helps a lot. I used it against 1.x and it applied there, too. I would set it to wait just a touch longer, but not too much. It still caught a few trips to the address bar but not as many.

Michelle

come on, Merlin, give us 250 :)

250 is too long to me, at least. Maybe I'm just impatient. Could see splitting the difference. =)

Merlin's patch doesn't apply for me with 6.x-3.x-dev:

patching file admin_menu.js
Hunk #1 FAILED at 37.
1 out of 1 hunk FAILED

Event Special Hover works well enough, but I've been using HoverIntent for over seven months without any problems, so I feel more comfortable with it.

I'm interested in testing Merlin's code but it doesn't look like it incorporates the main benefit of HoverIntent - which is that you don't have to wait for the menu to expand.

@Rowanw: The patch is against 1.x

Michelle

Sorry yes. I was directed here and I didn't notice the thread was for 3.x; my patch is against 1.x.

I'm interested in testing Merlin's code but it doesn't look like it incorporates the main benefit of HoverIntent - which is that you don't have to wait for the menu to expand.

Really? In the demos I saw I had to wait rather a long time for it to expand.

HoverIntent only fires when your cursor slows down to a set speed, so as soon as you get your cursor into position it should fire the event. People naturally slow down when hovering over a link anyway so they don't realise there's a 'delay'. There are two examples on the HoverIntent page - one's on default settings, the other has a 200ms interval which takes longer to fire.

Ah. Well, the delay in mine is so short that there's no real sense of waiting.

I just have to chime in to all the naysayers here that the usage statistics say different-- admin_menu is 6th on the list of most installed projects. Sixth! Moreover, all the projects above it have been included in core or are discussing/working toward core inclusion. It's also consistently in the 'top rated' and 'top downloaded' categories at drupalmodules.com. Sorry, but if we're going by the 80/20 rule here a handful of naysayers would be clearly in the '20' category. I'm quite confident that in this case the '80' will be disabling the core toolbar module and installing admin_menu but time, and usage statistics, will tell.

Yes I know these numbers are not absolute, but they can sure be used as a rough gauge. I have no clue of the details of the "not for novices" pronouncement (including the when, where, how, and who said it) so this is completely nonpartisan gut reaction on my part, but had it not been for some 'expert' pronouncement or the d7ux project, one has to wonder if this would even need to be a discussion.

And on a completely different tack, with all the important work to be done on core drupal, it seems really quite the waste of time to reinvent the wheel when an enormously successful tried and true contrib project, which has already worked out many of the same issues, is just waiting in the wings. It really leaves me head scratching.

Of course I don't yet contribute to core to this is all a big 'imo'-- take it or leave it.

@WorldFallz: Are you sure you're on the right issue? I know what you're talking about but I don't see how this relates to adding hoverintent? Did you get some tabs mixed up?

Michelle

Yep-- and then i accidently deleted it instead of unpublishing it. Sorry about that-- fat-fingering all over the place it seems. :-(

@WorldFallz: That's ok. :) Your point is very valid and I agree with you... just a little misplaced. :)

Michelle

Where is the right issue for what WorldFallz was talking about? I'd like to catch up :)

Didn't mean to stir the hornets nest, but you can see my post in it's proper context over at #543914: Administration menu or admin_menu should be in core. We now return you to your regularly scheduled issue....

It would be great to get this in. A really short delay of 75 to 100ms as Earl suggested would be a great usability improvement. 2.5 years after the original post and still no action - I'm assuming not everyone thinks it's a great idea.

yup, it's really annoying without the hover intent, unfortunately the above patch (from bevan) doesn't work with the latest release version , had to stuck with the 6.x-1.1 version here :(

Is there anyway to just make it stick to the left side and be a vertical menu instead of a horizontal?

Here's by initial question about it.

http://drupal.org/node/902946

Really wish this would be implemented in the stable release. I use multiple browser tabs and have to jump around between them a lot, which results in admin menu popping up quite a bit as I move the mouse around. A short delay would fix this for me.

Yeah, same here. I'm going across admin menu over and over and having the menu pop down in my way is annoying. I love Admin Menu too much to give it up, though. :)

Michelle

subscribe

3.5 years on - Gandhi would be proud of this thread! If there's going to be no action on this simple matter, perhaps it should be closed?

or one should create another admin menu maybe ?

As much as I'd like to see this added, threatening to fork isn't going to do anything but piss off the maintainer. It's set at "needs work". Maybe someone could go see what's needing work and fix it? Whole lot easier than forking, anyway.

Michelle

@Bevan: Well, that's how I read "or one should create another admin menu maybe ?" Dunno how you read it. At any rate, it's unfortunate this isn't getting in but the maintainer is pretty busy with core and maybe just hasn't had time to work on contrib.

Michelle

Ok, so I went back and looked. The patch is against 6.x-1.x and the issue is 7.x-3.x. That's not real likely to work at all. If someone who has the skills to do so would make a current patch and set it needs review, perhaps that would speed things up?

Michelle

He was 'about to commit' in July 09, last time he actually wrote text, so prob action is imminent/ish.

I asked on IRC and he was tagging the issue for "Google Usability Study 2012" but there seems to be some glitch that isn't showing the tag change in the comment.

Keep in mind that sun is extremely busy with core. There's only so much a person can do for one project.

Also note my comment in #86. Instead of making snide comments, someone with the js skills could be getting this issue RTBC.

Michelle

The patch in #58 can be applied pretty much as is to the current version, just do it manually. Any possibility of either getting this in, or a decision on the possibility of inclusion?

I use the patch in #58 on all the Drupal sites I build, it works really well.

Here are a updated version for the latest 7.x-3.x branch. I hope this will pass the test and get committed.

Forgot to set status.

I tested the patch from #94 and it's working, although the delay set for child lists is 100ms which is too quick for me, 300 is much more comfortable.

Tested #94: works perfect!
Everyone interested could test patched module here: [does not exist anymore]

- This is great!
- I also need at least 200ms rather than 100ms before expanding, and at least 400ms before closing the menu. Maybe this could be configurable in the admin menu settings...
- Each time I reload the page, it does not work the first time... :( I mean first time I hover over the admin menu, the hover intent does not apply, admin menu expands right away. After that it works fine, it waits 200ms.

I also need a 300ms delay. +1 for configuration.

The comment at the beginning of the JavaScript
// Delayed mouseout.
would properly be changed to
// Delayed mousein and mouseout.

This issue is 10 years old! You have to love Drupal.

Ten years old and something i needed badly so I just implemented today.
Sucks to hack modules, but this was annoying me almost to the point of uninstalling.
So glad I found this.

Thanks for the patch #94 – Is patching the module enough or will I have to install JQuery hoverIntent and http://drupal.org/project/hoverintent as well?

I want to say thank you to everyone here. I need more of your feedback and which number is the most comfortable delay before I can commit the patch.

Could someone please enlighten this question: Is patching the module enough or will I have to install JQuery hoverIntent and http://drupal.org/project/hoverintent as well?

The consensus so far seems to be:

• at least 200ms on mousein, 300ms probably preferred
• 400ms on mouseout
• If it's not too much to ask it would be nice to have those two values configurable under module settings

But the biggest impact/effort ratio would be just to implement the patch with 300ms either way.

I need more of your feedback and which number is the most comfortable delay before I can commit the patch (in #94).

I agree with portulaca's comment re: what the consensus seems to be. With that said, I'm not sure what the issue status needs to be at this point so I'll leave that up to you.

Also not clear whether the hoverintent module would be a dependency. My concern with that would be that the hoverintent module is both marked as minimally maintained and has no stable security-team-covered release.

The patch from #94 doesn't introduce any dependencies. It simply modifies the module code to make the menus wait just a bit before reacting.

It would be nice to finally have this implemented, there don't seem to be any opposing opinions.

agree 100% with portulacas comment.

@truls1502, re: your comment in #105:

I need more of your feedback and which number is the most comfortable delay before I can commit the patch.

Do you have the necessary feedback required in order to commit the patch in #94?

Works for me!

Thank you everyone, it has been committed. Closing an 11 year thread is extremely good!

Thanks @HongPong !