After trying different things and doing a lot of investigation, it seems like this won't be a trivial feature to add, for a number of reasons.

First of all, note that the maxHeight attribute in ace:menu only works for sliding menus (those that present only one menu/submenu at a time and slide to the left to display another submenu that was selected). In this case, the maxHeight feature is trivial because it's actually the same container that displays all the submenus, and it doesn't change in size or position.

In the case of ace:menuBar and flyout menus in general the situation is different. Submenus float next and on top of each other with varying positions and sizes depending on the menu hierarchy and menu items contained. The natural way to go about implementing this feature is to add the 'max-height' CSS property to the various submenus (represented by <ul> elements). After doing this, it is also necessary to specify an 'overflow' setting like 'hidden' or 'scroll' or 'auto' for hiding the contents that don't fit in the given height. The problem comes when we set this 'overflow' setting and then we want to display a floating submenu to the right (or left) of the currently active submenu; this submenu won't be immediately visible, because it will be clipped and it will be necessary to scroll horizontally in order to see its contents, as illustrated by the attached screenshot.

Using separate overflow settings for the x and y axes doesn't work. For example, using "overflow-y:auto; overflow-x:visible;" (so that a vertical scrollbar appears but the submenus are displayed in full to the sides) won't work, because the 'overflow-x' setting is automatically turned to 'auto' whenever a non-'visible' setting is used in the 'overflow-y' property (and vice versa), as per the W3C specification. This page discusses these browser and spec limitations: http://stackoverflow.com/questions/6421966/css-overflow-x-visible-and-overflow-y-hidden-causing-scrollbar-issue

Having stated the above, this feature can still be trivially implemented, but it would only make sense on menus that only have one level of submenus, since they wouldn't have the issue described above with submenus of submenus.

It seems that there could still be some workarounds to make things work as desired, but this would require more investigation experiments, and it's not sure if it would work with our current code. This involves adding some additional nodes to the markup and making significant CSS modifications, as well as modifying the Wijmo Javascript code used for the menu components, since it has specific expectations in regards to the HTML markup structure and styling of the menus.

Marking Closed/Won't Fix due to the technical difficulty in achieving this, combined with a concern regarding the viability of a UI based on this type of scrolling sub-menu approach.

Work-around recommendation for cases where you may have a data-driven menu with a potentially large number of menu-items (too many to display on the screen at one time) is to use a data-model driven dynamic menu structure, and insert "page" submenus as needed, with perhaps 10-15 menu items per page.