Cannot access menu items in too long menus when the menu is set to stick at the top of the page.

Menus below the fold is only one half of the story.
The other is, menus that push the body height, and cause a jumping scrollbar issue. This is especially relevant on pages with a small or fixed height.

For long pages, I don't mind to scroll the entire page, if my mouse does have a scroll wheel. And hey, admin menu is for admins, and admins have scroll wheels.

For shorter pages I see two solutions to avoid the jumping page height:
1. A scrollbar (overflow-y:auto) in the menu itself. I think I have seen this somewhere, and didn't find a problem with it.
2. Let the menus disappear to the left (left:-10000px) instead of "display:none;". This will push the bottom of the page down, even when the menu is not visible. However, this will make the entire page as high as the longest submenu - which is usually the list of modules on drupal.org. This might be unintended.
3. Make sure that the page does always show a vertical scrollbar. There is a documented solution for this, but I don't remember it atm.

----

One more problem I found: If the windows has no focus, the scroll wheel has no effect - but hovering does have an effect. You are stuck in the menu tree, because you would need to click somewhere to give the window focus - and this means, you need to leave the menu tree.

I too, have reached the point where I have too many modules installed and admin_menu is too long for the screen. Frustrating.

same here sun...

[copy-paste from #425832: admin_menu: implement mega-menus]:

@sun: please keep in mind that A LOT of people still use the D6 version and we surely want this. I mean, there is only 40-60 people trying the D7 while more than 110,000 use D6. Besides, if you implement this in D6 branch you'll have more people to beta test ;)

thanx.

Marked the following issues as duplicates:

#588708: Usability & productivity negatively affected by long admin menus
#425832: admin_menu: implement mega-menus

Similar to this one, the last issue suggested something like http://www.useit.com/alertbox/mega-dropdown-menus.html

subscribing from #425832: admin_menu: implement mega-menus

My opinion: scrolling menus will hurt usability badly because they potentially insert a "mess with a scrolling interface and things that are flying all over the place" step to find any menu item. Mega drop downs are superior to scrolling menus.

Mega drop downs are cool, but:
- The information stored with the current Drupal menu system does not tell us how to arrange things in a mega dropdown.
- To solve the vertical space problem, we would have to use multi-column mega dropdowns, and these are not designed to have drop/fly-out submenus themselves.

I use a program called True Launch Bar on my desktop, and it has long scrollable menus with fly-out submenus. My entire filesystem structure is accessible through these menu. I did not have problems yet.

One trick why this works is that the scrollbar is on the left. But even when the menus fly out to the left (which happens after I reach level 4), the scrollbar is not in the way.

That said, I can well imagine how nested scroll boxes (especially with javascript effects) will be clunky and horrible on the web.

Well-implemented mega-dropdowns + good information architecture = no flyouts.

Did you ever try ubercart, and count the menu items you get?
And do you honestly consider to arrange all CCK types and field instances in a mega dropdown, for a site with 20 types and each having 7 field instances? Even if you would manage to do this, the user experience would be horrible.

The benefit of flyouts/dropdowns is to have menu items out of the way if you don't want to see them. The admin menu typically contains a lot of things that you only want to see if you are explicitly looking for them.

Mega dropdowns are made for situations where you always want to show all possibilities (of one section of your site). This is a very different situation than what we have with admin menu.

good information architecture

Information architecture requires that you know the information. A generic tool like admin_menu knows nothing about the site you want to build.

What I propose is that you produce a nice editorial menu for your client, with the nicest information architecture that you can imagine. This is actually the same that i do - my clients will never see the admin menu (unless they want to do the admin stuff themselves). This menu will be special for every site I make, and I could imagine that in some situations I would make this a mega dropdown.

I would suggest to solve this in separate modules.

admin_menu_scroll could define a js and a css file that would make the existing admin_menu scrollable.

editorial_megadropdown would be a customizable dashboard menu, with little in common with the existing admin_menu.

#10 (separate module) makes sense. I am sure this isn't the only module that could benefit from mega dropdowns.

I played a bit with Firebug + admin_menu + overflow-y:auto.

Some problems I run into immediately:
- I get vertical and horizontal scrollbars. I guess I need to refresh my CSS skills?
- The scrollbars cut off the submenus that fly out to the right. Even worse, the flyouts make the horizontal scrollbar grow and shrink.
- If I scroll down and hit the end of a menu, the next scroll step will scroll the page instead. Trying to go back (scroll up one step) will not undo the page scroll, but instead scroll the menu up. This is a huge pain, and would require some evil javascript to fix.

Possible things to try:
- Wrap the ul elements in div containers (with javascript), if this proves useful.
- Try different CSS implementations: Don't make the li elements float, don't define a fixed width, etc. If it proves useful.
- Somewhere I read that direction:rtl would put the scrollbar on the left. No success with that so far.
- Higher z-index for deeper nested submenus.
- javascript to fight the vertical page scroll when you hit the end of the submenu scrollbar.

All of this appears hacky and ugly and unreliable to me, so I don't want this in the default admin_menu. For my projects I'm happy with admin_menu as it is now. Very happy. (I just like to write stuff in issues..)

I had another look at the example
http://css-tricks.com/long-dropdowns-solution/

The submenu on the left ("Really Tall Menu") has 39 items, says my notepad.
None of them has a child fly-out menu.

The "Site configuration" submenu of one of my projects has 45 items, with submenus.
The "drupal.org" probably has around 100.

A decent size for a submenu would be around 300px. With 100 items you would see a new item every 3 pixels of mouse movement.
The bigger problem is the sub-submenus, and how they will follow the scroll movement.

Now, whatever, let's just wait for some other contrib person to implement this.

Please note that parts of the most recent discussion here are intermixing a unrelated feature request: #336611: Allow to configure different menu to use for certain roles -- Regardless of the administrative menu that is rendered, the menu can still be too long.

FYI: I've re-opened #425832: admin_menu: implement mega-menus, because I now understood how mega dropdowns are supposed to work + look, which is entirely different from admin_menu's default styling.

We've been having the same problem, so I just created a patch that simply unfixes the menu while it's in use (so that when it goes off the bottom, you can just scroll down). When you're done, it fixes it back again.

I can expand the patch to make the new behavior optional if that's desired. If people like this solution, maybe this issue status can move to "needs review"?

I didn't even know about this issue until just now when I came around to gauge interest in the patch.

By the way, the patch was generated against version 6.x-1.5, because that's the version I use. I don't know if admin_menu.js has changed at all in more recent versions. I can make new patches against other versions too, if it is necessary. I would really like to see the problem go away.

WOAH. WHAT A CRAZY AND AWESOME IDEA IS THAT? I love you. 8)

Doesn't solve the cause, but super-definitely solves the trigger.

wow, and @donquixote - sorry, I didn't really recognize your link to http://css-tricks.com/long-dropdowns-solution - that's actually exactly what I had in mind! We should definitely try to turn this into a patch, make it optional, and crowd-source feedback on it.

wow, just wow... on it.

Subscribe.

wow.

All open todos are documented in-code.

Resolves some further @todos, introduced new ones :P

At this point, this patch is against D6.

wow, and @donquixote - sorry, I didn't really recognize your link to http://css-tricks.com/long-dropdowns-solution - that's actually exactly what I had in mind! We should definitely try to turn this into a patch, make it optional, and crowd-source feedback on it.

This wasn't me, it was a quote from the topic starter. You need to read better :)
My own post was rather a critical reflection of that idea. The solution as advertised does not have sub-submenus, and I'm not sure how well they would work.
If this is going to make it into admin_menu, I would very much appreciate if it was optional. .. EDIT: and I also need to read better.

First tests show that it seems to be working just fine. Even submenus. Even sub-submenus. Even sub-sub-submenus ;)

For example, tested in the ImageAPI menu:

Site configuration -> ImageAPI -> Configuration -> ImageAPI GD2

I didn't just hover to see the menu children open or simply look at the URL in the browser's status bar on hover. Everything really works!

The only (trivial) issue I came across was that it reaches almost at the end of the menu. It leaves two or three menu items off the bottom end of the browser and you need to scroll a bit. Minor thing as I said.

Now, all that remains to be done is (perhaps) some way to control the speed it scrolls + the @todos.

Thanx people for making a great module even greater! Keep it up.

@TravisCarden & everyone: Sorry for not properly reading this thread. I already lost hope when I first saw it, as we had another (duplicate) issue languishing around for 2 years until I finally won't fix'ed it... ;)

@donquixote: Although we can make it optional... heheh - did you try the patch? It's an entire rewrite of that script/plugin, which works smoothly with expandable sub-menu-trees. ;)

@klonos: Thanks for testing! A couple of questions on your feedback:

1) Which browser/platform did you test on?

It leaves two or three menu items off the bottom end of the browser and you need to scroll a bit.

2) Does this happen on all levels or only on the third-level and below (i.e. below expandable items)? I'm asking because it didn't happen for me, and my "test" was to open Firebug (docked) and make the Firebug console almost as large as the window, so I was able to test various menu lengths.

(perhaps) some way to control the speed it scrolls

3) Is it too fast or too slow? Originally, that script was convoluted with some accelerated animation depending on the menu length. I found it totally wonky and unusable that some menus scrolled faster and some slower. On my client/browser (which is not really representative), the speed is just right. Though I yet have to test on a real client.

1) I basically use firefox nightly builds (latest 3.7pre alpha releases) on WinXP SP3 and that was what my previous feedback was based on. I have various testing environments available though (I even have a Mac OSX setup laying around) and I can test if need be. I had the search bar open at the bottom and initially I thought that this was the culprit, but disabling it had the same result. In the meantime I tested it on IE8 as well and it doesn't happen there. All the above was in a 22'' monitor with 1680x1050 resolution.

I also tested both firefox 3.6 (vanilla profile - no status bars) and IE8 on my laptop that has a 1366x768 resolution. There, the menu items left off the bottom end are like a dozen or so. That is in both browsers.

I then went on and tried your test with firebug in order to shorten the viewable area. Again in this case more than a few menu items are left off.

From all the above I came to the conclusion that it is not browser specific. Even in the large resolution monitor the issue might only appear in firefox due to the toolbars + multiple tab bars used making the viewable area shorter.

I can provide screenshots that display the situation if you need them.

2) It happens on 1st level only (my sub-menus aren't that long, sorry). To be exact it only happens on the Site configuration menu, since I have a lot of modules and that is the only menu with enough items so that the menu can reach the bottom of the screen.

3) Actually too fast I think. I noticed that the scrolling effect 'stops' over items with sub-menus, but I guess that it is intentional + I personally want that to behave this way. The only side-effect of this behavior is that if there is a series of items with sub-menus on a row (4 or 5 of them for example), when the mouse pointer reaches the last item with sub-menus and moves down to the next one without, it short of 'jumps' there. That fact in combination with the fast speed makes you miss/skip a menu item or two and you need to move up again.

All the above tests and behavior notices were made in a custom theme. I can switch to a core theme and test again if you want me to.

All these aside, this still remains a great improvement and I didn't expect it to come bug-free in the first run. All I mean to say is that all these quirks seem necessary (minor)evil to me compared to the improvement introduced. I am confident we'll sort these issues out in time ;)

Thanx again.

Wow....that's actually...really awesome. Only wish it didn't scroll so fast. :)

Now including excessive insane menu tree testing code. Make sure you have a max_execution_time suitable for development/debugging sites. ;)

Could someone publish a demo?
I don't have a patch tool and test environment available atm..

And this testing tree reveals that it's totally broken :P

Re-testing all quirks reported in #29 with most current patch v31 from post #31...

- This fixed the issue where a 1 or 2 of the last menu items were off in the large monitor with the 1680x1050 resolution. So, it now works perfectly for both firefox and IE8. The issue quirk still remains in the low res monitor in both browsers and the items off are about a dozen or more.

- The quirk where the menu 'jumps' and skips a few items when mouse leaves a series of menu items that have sub-items, still remains.

- I didn't realize any change in the speed, but it was several hours back since I tested patch v24. So, I either don't remember the feeling of the previous speed or I am simply starting to get the hang of it. Whichever it is, it's good news ;)

Thanx.

PS: I've just realized that you use post numbers to version your patches and in #22 CrashTest_ just hit the save button before you ;)

So, in my above post instead of 'patch v31 from post #31', either 'patch 31' or 'patch in #31' would suffice.

[Sorry for polluting the issue queue]

If I may... I would like to propose two small improvements.

For most people, the only menu that seems to be getting rather large and reaches the height of their browser's viewable area is the 'Site configuration' (most modules like to add entries there). So, for most of us, this feature would apply mainly (if not only) to that menu. Well... unless we use firebug in small-size monitors of course ;)

Moving from one menu to another feels the same. With this feature added, moving to the 'Site configuration' menu feels as if it uses a different logic. If not much of a trouble, can you please make it so that the css trick is activated only when someone hovers over say the 4th or 5th menu item and moves downwards? Perhaps that threshold could be the 50% of the viewable area or 50% of the menu size?

Also, as it is now, the css places the scrolling menu above the admin menu row. As a result, the current menu's title is not visible while the scrolling menu is activated. Perhaps placing it a level behind the menu row would be better(?).

Trivial thingies. I can live with them though. If you decide they are nice to have additions, but other things are critical right now, you can add them to your @todos.

Thank you in advance.

This is marked for review?

I've just upgraded to 6.x-3.0-alpha4 and have the tickbox set to keep the menu at top of page. I don't see any change in behaviour for long menus. (FFox 3.6.3/WinVista)

Should I be applying the patch from #31? Wasn't clear: the patch seemed to start off against 6.x-1.5...

The Admin Menu rocks. Thanks for an absolutley core piece of Drupal usability.

This worked awesome for me. Super easy. Perfect. Thanks!!!

admin_menu-unfix_when_in_use-687750.patch

subscribe

I used admin_menu.long_.20.patch and its great in FF3.
This is most admins browser. It should be released like that for dev.

THanks

...the menu disappears when you get close to them or scrolls past three at a time.

True! This issue still remains. @Travis: can you please confirm that this 'jumping' or 'skipping' of some menus happens only after hovering past menu items that have sub-menus?

Hey folks,

Nice to see the menu scroller thing I tinkered with potentially being put to good use. Let me know (emailing me at chriscoyier@gmail.com is the best bet) if there is something I can help with related to that specific functionality. Looking back through the comments on that post someone linked up an idea to prevent the menu from going beneath the fold too, which is kinda neat: http://geek-like-me.com/example/LongDropdowns-plugin/

-Chris

Good news. Welcome on board Chris!

subscribing

just checking -- there hasn't been a DevRelease of 6x-3x since 2010-Mar-12 ...

possible to refresh *with* this fix so we can test? or, is the presumption that we apply patch (@ #31 ?) to the 2010-Mar-12 release?

Thanks!

Here's a quick hack workaround that will work for some people: differently sized menu items for different menu items.

This could solve some user's problems such:

a) Admin Menu "wrapping to two lines" (it does if you have a non-widescreen monitor and then you install Ubercart, Project and a handful of other modules needing "top level" Admin menus).

b) Cascading menus becoming too long to fit on the screen

c) Maybe you want to shrink stuff most of your team never uses, or color-code menu items, etc..

Here's the CSS to do just that. Put it in a CSS file that loads AFTER admin_menu.css. Worst case, tack it onto the end of menu_item.css (but you will need to re-apply when you upgrade the module...)

Here I wanted to style top-level menu for Advanced Help, Help, and Project:
#admin-menu li a[href="/admin/advanced_help"],
#admin-menu li a[href="/admin/help"],
#admin-menu li a[href="/admin/project"] {
font-size: smaller;
}

OK. Now let's say you want to style all the menus nested UNDER something - meaning all second level menus.
Target the URL same as above, but use the ^= "begins with" in attribute selection so you cat aim at a commonly-shared href value:
#admin-menu li a[href^="/admin/project/"] {
font-size:larger;
}

NOTE: [href^="/admin/project/"] would only target the nested items because the parent menu item's href does not match (notice the extra "/" on the sub-menus... as in "/admin/project/...")

EDIT: Here's how you would shrink all the "Create Content" menu items... I should have made that my example as it's the most common request...

#admin-menu li a[href^="/admin/node/add/"] {
font-size:smaller;
}
... You can also specify font-size in pixels, but the smaller/larger type keywords tend to play nicer with different platforms..

EDIT2: This was tested on FireFox 3.6.3 only. I didn't look into cross-browser testing or browser hacks in the CSS (it's an Admin bar and everyone here uses FireFox).

checking in for news on this, is the available update,

6.x-1.x-dev Download (51.16 KB) 2010-Jul-11 Notes

'real', or an artifact of yesterday's

"Packaging script incorrectly removes -dev tarballs when there's no new code to package"
http://drupal.org/node/850340

?

#31: admin_menu.long_.31.patch queued for re-testing.

Tested patch from #31.

My config:

• XP
• Toolbar Style activated
• Using the latest version of all mentioned browsers
• Drupal 6.19
• Trying with a 54 item long list
• A few other JS inserting modules are active, like Feedback and Floating Manager Menu
• Tested on both a simple older netbook and a bit more powerful notebook (sorry, I don't use desktops)

Browsers (from best to worst perfoming with this patch):

• Chrome and Safari (Windows version) OK
• 14 items not reachable on the netbook screen (h:600px)
• Scrolling pretty smooth, even on the netbook.
• Mozilla OK
• 25 items not reachable on the netbook screen (h:600px). Might depend on my minimum font size settings.
• Scrolling was the smoothest of all browsers
• IE8 (on the notebook) OK
• Could not test how many items were unreachable on the netbook screen. On the notebook all items were reachable.
• Scrolling pretty smooth
• Opera (on both netbook and notebook)
• Functionality works the first time or after cache clear, but might disappear after using it a bit on the same page. Magically it might appear again on a new page. Can not reproduce. Seems quit unpredictable behaviour. It's not crashing though and still working like without the patch.
• IE7 (on the netbook)
• Slow, unacceptable slow, to open the dropdown on hover (>20 sec). Made a comparison with a similar site with only Toolbar Style but without the patch applied. Both make the opening of the dropdown on mouseover slower, but the patch in an extreme way. I have to say that I have all mentioned browsers opened contemporarily on my poor netbook.

I use Chrome and Safari, the other ones only for testing purposes, so I am very happy. The patch seems to work for most browsers, except IE7 and partially for Opera. Thanks a lot for your work on it.

EDIT:
After using it a while, noticed that sometimes the dropdown drops down itself, sometimes even disappearing from the pages. Result is a gap between the main menu bar and the dropdown. When you move down your mouse pointer that starts always on the main bar, the dropdown closes before you had time to reach it. Sometimes it happens more than others, on both long and normal dropdowns and doesn't seem to be browser related.

subscribe

As a temporary workaround there is a patch for the alpha4 3.0 release that allows you to disable Admin menu items. #282775: Hide disabled menu items - Comment #11

Subscribe

When I use Cygwin to Patch the file "admin_menu.long_.31.patch" at #31
have some error below:

$ patch -p0 -b < admin_menu.long_.32.patch
patching file admin_menu.js
Hunk #1 FAILED at 198.
1 out of 1 hunk Failed -- saving rejects to file admin_menu.js.rej
patching file admin_menu.module
Hunk #1 succeeded at 67 <offset -15 lines>.

How can I do anything?

Try to apply the patch manually: http://drupal.org/node/534548

while waiting for a patch, a different approach would be to re-organize the management/admins menus, so they are nested, but is unpratical as automated solution. you have to do it manually per site.

or use instead Admin, as i do

...no feature request can be critical and the issue reported here breaks the module's functionality. So, we should definitely consider this a bug. It is not specific to any browser and there is no flaw in the CSS to fix. This has to do with an architectural problem of the UI when menus get too long. When they do, the issue occurs in every browser AFAICT.

The issue was set to "needs review" back in 2010 and there's a patch available in #31, but I believe that it was for 6.x. Anyways, it was a really long time ago and it needs to be rolled for the 7.x branch ...that is if the way we choose to go back then is applicable in 7.x and still viable.

The issue summary does have the original report but does not reflect the discussion. It should sum up any proposals made and/or decisions taken since then. What are we doing here? Do we have a solution figured out? From what I recall, the two most discussed proposal were either to go with #425832: admin_menu: implement mega-menus or implement Chris Coyier's solution for very long dropdown menus.

If everyone (and most importantly @sun) agrees with these changes I propose, I'm willing to go through the issue and update the summary in order to help with evaluating the ideas proposed in the past and possibly coming up with a solution.

Let me know.

...just a thought: converting admin_menu to a mega-menu might indeed solve the issue at hand, but I think introduces the risk of 2+ level menus not fitting the screen width (we solve the "too long" issue but risk introducing a "too wide" one). Besides, doing this conversion probably means re-writing the way the module works almost from scratch.

I believe that the js solution for too long menus (btw, should we call this method "scrolling menus"? - it seems fitting) addresses the issue based on the architecture we currently have and thus will require less work. So, I think it's worth trying first.

...take a look at this: #1586374: New toolbar

I needed a solution for this on a project and have created a patch based on Chris Coyier's Solution For Very Long Dropdown Menus mentioned in the original issue description. The other patch on this thread is now very out of date and didn't seem to work.

My patch is not 100% there - probably needs cleaning up and any edge case issues fixing so people should feel free to have a bash at sorting what I've done so far.

Updated new patch to fix an issue.

Fixed file path in patch from #64.

Patch in #65 doesn't apply to admin_menu 7.x-3.x-dev
Manually applied changes and it works somewhat but not completely.

Without patch a long menu list like the drupal.org modules list extends to bottom of browser window and is stuck.
With patch the long menu of drupal.org modules scrolls as an independent column but doesn't show all modules, only goes about three quarters of the way down and then disappears as if user has moved off the menu.

This seemed to work at first but is buggy. You can no longer access the top items in the long menu list as it won't scroll all the way to the top, only the bottom.

Applied manually patch at #65 and works great. No problems reported, nor even #67. This should be included definitelly.

Created patch for 7.x-3.x-dev after #65. As I said it works for me.

This doesn't work for me. I have a long list of views under Structure -> Views and it still goes off screen

This patch works stlitghly better.

I am sorry for no reply until now.

There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.

We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.

However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.

So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?

Thank you for understanding! :)

This issue has been automatically marked as closed because it has not had recent activity after the last post.

However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.

Again, thank you for your contributions! :)

In followup to comment #78 this is still an issue and can be demonstrated by looking under the admin menu icon menu at the drupal.org sub menu for issues on drupal.org where the menu items extend beyond the bottom of the screen. The last patch in #76 does not apply which is not surprising considering the number of changes especially related to hover in #220100: Add support to detect hover intent (no dependencies added).

@izmeez can you reroll #76 for us and to check if work?

@thalles Attached is a reroll of patch #76 as requested.
Brief testing shows it now does not show admin menu icon -> drupal.org -> submenu for issues. This definitely needs work.

To test this it is necessary to go into the admin_menu Performance settings and enable " Show Issue Queue links in icon menu".
Then go to the admin menu icon and the drupal.org item to view the submenu of issues that extends beyond the viewport and there is no way to go to menu items below the bottom.

If the admin_menu setting "Keep menu at top of page" is not checked then one is able to scroll down the page to see all items on the long menu. However, I think the intent of this issue/feature is to allow the menu to stick to the top and have long menus scroll up as needed. To do this more work is needed.

In my environment it's like this:

@thalles you will need a test site with a long menu. The test site I used had a bunch of modules installed so the issues submenu was long enough to extend beyond the bottom of the screen. Just for good measure, I have also tested it with the default Bartik theme with same results.