Pop up menus popup on the hover event, which is triggered even when you pass the mouse over the menu on your way elsewhere. This is annoying.

jQuery plugin hoverIntent exists to provide an event similar to the hover event but that more accurately calculates whether the user is just passing over and when the user actually is aiming for the hover target area. There is also a drupal module packaging the jquery plugin: http://drupal.org/project/hoverintent

Support for hoverIntent, with or without dependency, would make this menu very much more usable.

Files: 
CommentFileSizeAuthor
#94 hover-in-delay-94.patch1.97 KBfrjo
PASSED: [[SimpleTest]]: [MySQL] 228 pass(es). View
#58 hover-in-delay.patch2.03 KBmerlinofchaos
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch hover-in-delay.patch. Unable to apply patch. See the log in the details link for more information. View
#54 220100.patch757 bytesBevan
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100_2.patch. Unable to apply patch. See the log in the details link for more information. View
#53 admin_menu.patch776 bytespatrickharris
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in admin_menu_24.patch. View
#53 jquery.event_.hover_.js.txt3.46 KBpatrickharris
#43 220100.patch2.45 KBBevan
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100_1.patch. Unable to apply patch. See the log in the details link for more information. View
#43 jquery.hoverIntent.js.txt4.43 KBBevan
#37 220100.patch2.41 KBBevan
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100_0.patch. Unable to apply patch. See the log in the details link for more information. View
#35 220100.patch1.74 KBBevan
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100.patch. Unable to apply patch. See the log in the details link for more information. View
#35 hoverintent.js.txt4.41 KBBevan
#20 admin_menu.hoverintent.patch7.56 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.hoverintent.patch. Unable to apply patch. See the log in the details link for more information. View
#16 admin_menu_intent.patch7.59 KBRowanw
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent_2.patch. Unable to apply patch. See the log in the details link for more information. View
#13 admin_menu_intent.patch6.15 KBRowanw
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent_1.patch. Unable to apply patch. See the log in the details link for more information. View
#12 admin_menu_intent.patch6.17 KBRowanw
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent_0.patch. Unable to apply patch. See the log in the details link for more information. View
#9 admin_menu_intent.patch3.21 KBRowanw
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

sun’s picture

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.

Bevan’s picture

please try out the hoverIntent demos at http://cherne.net/brian/resources/jquery.hoverIntent.html

eigentor’s picture

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?

sun’s picture

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

Bevan’s picture

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

I completely disagree. Due to the menu's orientation and dimentsions, it often occupies 95 to 100% of the screen-width (not browser width) and 20 or 30 pixels vertically. That means that every time the user moves the mouse from the browsers page-area to the browser's toolbar, menu, url bar, bookmarks or search box, the mouses passes over (albeit not for long) admin_menu. The menu pops up and distracts them from their task. This occurs frequently in an average browsing session. Having a delay on mouse-out exaggerates this issue because the distraction lingers for even longer.

A mousein/onhover delay would help resolve this issue, but then you don't want to delay the showing if the user is actually intending to open the menu, and not just passing over. hoverIntent deals with this issue effectively.

yched’s picture

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 ? :-)

sun’s picture

Title: menu pops up too easily, even when you pass over the menu » Add hoverintent support

Better title.

johnhorning’s picture

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.

Rowanw’s picture

Version: 5.x-2.x-dev » 6.x-1.x-dev
Assigned: Unassigned » Rowanw
Status: Active » Needs review
FileSize
3.21 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent.patch. Unable to apply patch. See the log in the details link for more information. View

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.

Rowanw’s picture

Version: 6.x-1.x-dev » 6.x-1.1

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

sun’s picture

Status: Needs review » Needs work

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.

Rowanw’s picture

Status: Needs work » Needs review
FileSize
6.17 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent_0.patch. Unable to apply patch. See the log in the details link for more information. View

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

Rowanw’s picture

Version: 6.x-1.1 » 6.x-1.x-dev
FileSize
6.15 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent_1.patch. Unable to apply patch. See the log in the details link for more information. View

Woops, in a rush...

cdale’s picture

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.

Rowanw’s picture

Status: Needs review » Needs work

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.

Rowanw’s picture

Status: Needs work » Needs review
FileSize
7.59 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu_intent_2.patch. Unable to apply patch. See the log in the details link for more information. View

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.

Bevan’s picture

Status: Needs review » Reviewed & tested by the community

Woohoo! I'm so excited this is finally implemented. Applies to admin_menu DRUPAL-6--1 and works like charm; http://www.youtube.com/watch?v=5qAdCaWeBpA

patrickharris’s picture

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

sun’s picture

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

sun’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
7.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.hoverintent.patch. Unable to apply patch. See the log in the details link for more information. View

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)

Bevan’s picture

Hmmm. It worked everywhere for me. Can you check if hoverIntent.js is loading into the page correctly by calling it from firebug once the page has loaded? Can you also verify your browser has loaded the modified file by checking it's source code via firebug? Do you have js-compression turned on?

sun’s picture

Yes, yes, even checked both.

Rowanw’s picture

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

sun’s picture

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

Bevan’s picture

Odd. And no errors? You've got firebug's console turned on? How frustrating.

Rowanw’s picture

Sun, D5 or D6?

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

frjo’s picture

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.

Bevan’s picture

> I have tested this on Drupal 5 and it works really well!

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

frjo’s picture

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

sun’s picture

Version: 6.x-1.x-dev » 6.x-3.x-dev
jeromev’s picture

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

Bevan’s picture

Sun, have you been able to get this working in your sandbox? Did you ever work out what the issue was?

It would be great to get this committed.

sun’s picture

Status: Needs review » Needs work

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

Bevan’s picture

Assigned: Rowanw » Bevan
Bevan’s picture

Status: Needs work » Needs review
FileSize
4.41 KB
1.74 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100.patch. Unable to apply patch. See the log in the details link for more information. View

Rerolled for DRUPAL-6--3.

I removed the CSS, since it appeared to be unnecessary.

Rowanw’s picture

Status: Needs review » Needs work

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.

Bevan’s picture

Assigned: Bevan » Unassigned
FileSize
2.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100_0.patch. Unable to apply patch. See the log in the details link for more information. View

Ah, I see. Thanks for that Rowanw. I was worried I might be reintroducing a bug by removing that code, but I didn't notice that bug and didn't understand the inline comments.

This version of the patch fixes that issue, though in a different way to #16, since it appears that no-JS is not supported in admin_menu v3. Therefore the simplest solution is to entirely remove the offending CSS.

It appears there is more CSS in admin_menu.css that is redundant now that admin_menu does not support JS-less browsers. However that should be dealt with in a separate issue.

I have only tested this in FF3 Mac and Safari 3 Mac, since I first want to get some approval from Sun or another maintainer that we are going in an acceptable direction with this, and that admin_menu 3 will indeed not support JS-less browsers.

sun’s picture

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.

Bevan’s picture

The entire menu structure is added solely via AHAH – which requires javascript. How did you anticipate a JS-less version might work?

We could do this optionally depending on the presence of hoverintent, however we'd need to rewrite that module for drupal 6 and the new jQuery versions and techniques. Further, this feature is so beneficial to the user-experience, that it would be a waste to add it conditionaly. Hoverintent isn't really very big. concatenating and minifying javascript has a significant impact on performance if you (or others) are concerned.

patrickharris’s picture

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.

portulaca’s picture

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?

Bevan’s picture

I think that hoverIntent does more than just add a 200 ms pause before activating the hover. I think it analyzes the speed and acceleration of the mouse cursor to determine whether the user was targeting the element it is currently hovering over or not.

Sun; Where is the 3 branch at? Where is this feature at? How can we get this into admin_menu?

Bevan’s picture

Status: Needs work » Needs review
FileSize
4.43 KB
2.45 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100_1.patch. Unable to apply patch. See the log in the details link for more information. View

Sun and I worked this out and I rerolled the patch accordingly. Attached, along with a renamed hoverintent file with CVS $Id$ tag.

Rowanw’s picture

Status: Needs review » Reviewed & tested by the community

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

Bevan’s picture

woohoo!

mcrittenden’s picture

Subscribe. This would be nice.

jeromev’s picture

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

sun’s picture

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?

portulaca’s picture

I vote for the first level only ;)

patrickharris’s picture

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?

Bevan’s picture

I think eventspecialhover is a better solution to the second-level hover issues. I'll re-roll the patch if there is consensus

mcrittenden’s picture

Status: Reviewed & tested by the community » Needs work

+1 for eventspecialhover from me too.

patrickharris’s picture

FileSize
3.46 KB
776 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in admin_menu_24.patch. View

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

Bevan’s picture

FileSize
757 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 220100_2.patch. Unable to apply patch. See the log in the details link for more information. View

The same patch but applies and conforms to http://drupal.org/patch/create.

Bevan’s picture

Status: Needs work » Needs review

The method of special event hover doesn't seem to be as effective as hoverIntent to me. But I'm not sure if this is because it's difficult to intentionally simulate realistic behaviour, because FF tabs are next to the admin menu links, or it's just not as effective.

The patch is far simpler than the hoverIntent one, though it wouldn't be difficult to employ a similar technique as special event hover, which is to rename $.fn.hover to $.fn._hover and rename $.fn.hoverIntent to $.fn.hover. I wouldn't recommend this though, since it will affect other users of jQuery.hover(), possibly adversly (though probably for the better in many/most cases).

Both libraries solve the problem and I'd be happy with either getting in. hoverIntent seems to do a better job IMO.

patrickharris’s picture

Status: Needs review » Reviewed & tested by the community

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?

Bevan’s picture

Priority: Normal » Critical

patrickharris, I don't think that it is an issue, since not using hoverIntent on those results in flashing all the items you pass over on your way to your destination; which is part of the problem we are trying to solve. I guess it's a matter of opinion, which I think is affected by how fluent you are with your pointing device and how used to the flashing menus you are.

Temporarily bumping to critical to get attention from maintainer.

merlinofchaos’s picture

FileSize
2.03 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch hover-in-delay.patch. Unable to apply patch. See the log in the details link for more information. View

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.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Needs review
Michelle’s picture

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

eigentor’s picture

come on, Merlin, give us 250 :)

merlinofchaos’s picture

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

Rowanw’s picture

Status: Needs review » Needs work

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.

Michelle’s picture

@Rowanw: The patch is against 1.x

Michelle

merlinofchaos’s picture

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.

Rowanw’s picture

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.

merlinofchaos’s picture

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

WorldFallz’s picture

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.

Michelle’s picture

@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

WorldFallz’s picture

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

Michelle’s picture

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

Michelle

mcrittenden’s picture

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

WorldFallz’s picture

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

sun’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
patrickharris’s picture

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.

rei’s picture

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 :(

xl_cheese’s picture

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

LudachrisGSX’s picture

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.

Michelle’s picture

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

mrogers’s picture

subscribe

patrickharris’s picture

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?

rei’s picture

or one should create another admin menu maybe ?

Michelle’s picture

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’s picture

Who is threatening to fork?

AFAICT the maintainer is not on-board with this feature. But it would be nice if they could be more explicit and just say "no" or otherwise state what reservations they have about the feature.

Michelle’s picture

@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

Michelle’s picture

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

sun’s picture

Bevan’s picture

Oh bummer. We almost got input from the maintainer! But didn't. :)

patrickharris’s picture

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

Michelle’s picture

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

sun’s picture

Issue tags: +GoogleUX2012
chertzog’s picture

Status: Needs work » Needs review

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?

Status: Needs review » Needs work

The last submitted patch, hover-in-delay.patch, failed testing.

frjo’s picture

FileSize
1.97 KB
PASSED: [[SimpleTest]]: [MySQL] 228 pass(es). View

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.

frjo’s picture

Status: Needs work » Needs review

Forgot to set status.

portulaca’s picture

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.

Leksat’s picture

Status: Needs review » Reviewed & tested by the community

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

Bevan’s picture

I think the configuration of hover intent there is great!

Nicolas Bouteille’s picture

Issue summary: View changes

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

Dave Reid queued 94: hover-in-delay-94.patch for re-testing.

Charles Belov’s picture

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.