Committed fix to 4.0 trunk at revision 43578 and to 3.3 EE maintenance branch at revision 43579.

After trying different approaches, using the CSS property white-space:nowrap; worked best. There's still the issue that when using icons, they won't appear aligned with the label when the label is the widest one in a submenu, even though they are supposed to be aligned by using white-space:nowrap, this doesn't happen because of other necessary CSS involved. Anyway, all this can be fixed at the app level with custom CSS and other workarounds.

Regression test (/submenuResize.jsf) added for ace:menu, ace:menuBar, ace:contextMenu:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/menu
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/menuBar
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/contextMenu

Attaching screen shots for ace:contextMenu on IF4 trunk vs EE-3.3 maintenance branch.

Reopening as there are styling issues with showcase demos and QA test applications. See attached screen shots.

r43878: committed fixes to 4.0 trunk for all styling issues with menu items and submenus.

Tested with ICEfaces 4 trunk r43878. There are still issues present in showcase and the QA test apps when using a sliding or tiered menu.
1.) The 2nd level tiered submenus with a small label are still displayed in a very wide container, see screen shot titled contextMenuTooWide.png. Test app /submenuResize.jsf
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/contextMenu

2.) Sliding menus do not resize to fit the label content, therefore text is overlapping in the submenu, see screen shots titled sliding1.png, sliding2.png. Test app /submenuResize.jsf
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/menu

3.) Showcase ContextMenu > Delegate. When mousing over the dataTable the initial contextMenu appears too wide, see screen shot showcaseContextMenu1.PNG. When clicking on the contextMenu the second menu is not wide enough for the data present, see screen shot showcaseContextMenu2.PNG

r43900: committed more fixes for various submenu and menu item styling issues, including the context menu issues reported above.

Trying to fix all these styling issues often results in introducing new issues to other menu components or parts of them. In the latest commit, new CSS rules and classes were introduced to try to keep some styling rules separate between the various menu components.

Note that this feature of setting width depending on contents was never meant to work on sliding menus, since the width could vary from page to page of the sliding menu, and it is meant to keep the same width at all times. However, we should still test that it's not affected by these changes.

Testing notes: please verify that no new styling issues were introduced in this latest commit in all browsers and report any issues found.

IF4 trunk r. 43901 testing results (IE11, Chrome39, FF34):
The tiered menus have been resolved in the QA test apps (issue #1 above), while the sliding menu in the ace:menu QA test app is still an issue (issue #2).

In showcase > ace:contextMenu > Delegate: in the initial submenu is still too wide, and the arrow renders now underneath the text (all browsers). The second menu being too small for the data present is caused by the wrong data formatting, and is now a separate JIRA, ICE-10444.

r43924: fixed sliding menu styling issues; added a way to specify sliding menu width.

Note that sliding menus are not supposed to adjust their width to fit their contents. This type of menu was originally intended for mobile devices and it's meant to maintain the same width across menu tiers.

The width of a sliding menu was previously set with the '.wijmo-wijmenu-ipod' CSS class. While this is still possible, a new and more intuitive way to set the width of a sliding menu would be by means of the following CSS rule:

.ice-ace-menu-sliding .wijmo-wijmenu-container {
	width:180px;
}

Testing notes: Please test all these components again, since some general modifications were made in the previous approach used to support this behaviour.

Did you check these changes on older browsers?
After previous commits we notice unwanted and not backward compatibile changes in custom styled menus under Firefox.

This feature can't be backwards compatible regarding custom-styled menus. To support this feature, it was necessary to make big changes in the core menu styling, having to do with positioning, floats, widths, etc. So, all custom styling will have to be adjusted to these new changes. There's just no other way around it.

r43927: backported fix to 3.3 EE maintenance branch.

>This feature can't be backwards compatible regarding custom-styled menus
Work but youe stylesheet need two changes.

.ice-ace-menu-bar .wijmo-wijmenu .wijmo-wijmenu-link > .ui-icon {
    top: 0;
}
.ui-widget.ui-widget-content.wijmo-wijmenu {
    display: block;
}

The first suggested change is ok. It doesn't cause any visible change in our test apps, but it's still valid, since 'top:0;' was already added to sliding menus, where it was necessary, and it just reinforces the way we want the arrow icon to be displayed.

The second rule can't be changed, since we need it to be 'display:inline-block;', otherwise, the menus, menu items and submenus take all the width available on the page, which is what this JIRA is trying to change.

r43952: Moved cursor styling to renderer, as before, to avoid applying it to disabled menu items; added 'top:0;' to arrow icons. Committed to 4.0 trunk.

Tested ICEfaces 4 trunk r43958. Tomcat 7 all browsers. Menu in ui:repeat now displays menus horizontally instead of vertically. This was not an issue r43873. Please see screenshot menuRepeat.png.
Test app menuRepeat.jsf
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/menu

Showcase MultiColumnSubmenu > Overview demo - Multi2 Menu has odd spacing between rows of menu items and flows past the width of the demo. Please see screen shot showcaseMuliColumnSubMenu.png

Arturo. Both rules was added for backward compatibility and works with app from trunk, modern FF18&up and even old FF3.6

>.wijmo-wijmenu .wijmo-wijmenu-link > .ui-icon

this is for old browsers because icon was too low , new browser don't use that

>ice-ace-menu-bar .ui-widget.ui-widget-content.wijmo-wijmenu

block because inline destroy layut of main horizontal menu with two level submenus

r43982: added styling rules to make the root node of ace:menu display like a block element, as before (and without stretching the menu contents).

r43984: decreased the menu column of the 'Multi 2' menu in the Showcase MultiColumnSubmenu > Overview demo, to make it fit better on the page.

Note that this fix doesn't apply to multi-column submenus, as each individual ace:menuColumn component has a width attribute (with a default value of 200 pixels) that determines the width of that column. Perhaps, in the future, a boolean attribute could be added to ace:menuColumn to ignore the specified width and automatically adjust the width to its contents. However, this has already been tried before, but it hasn't been possible to accomplish because of other styling constraints in the menu components.

Krashan, as I said before. The first rule you suggested (top: 0) is valid and has already been committed to our code. Thank you.

The second rule (display: block; ) causes other styling issues that are visible in our internal test applications. And these issues are visible in the other menu components as well (the contents of the menus are stretched to take the entire width of the page). It might look ok in the showcase application, but that might be because of other custom styling in that application in particular.

The ace:menuBar component, including the root menu, now only takes as much width as it needs, without stretching to the end of the page. This was done on purpose. However, it's debatable whether the root menu of ace:menuBar should take the whole width of the page (as before) or just take no more than it needs. We will review that in a meeting, In any case, to stretch the root menu of ace:menuBar the following rule would be more appropriate, in order to avoid affecting other menu components.

.ice-ace-menu-bar > .wijmo-wijmenu-horizontal {
	display:block;
}

r44001: committed some fixes to the 3.3 EE maintnenance branch: fixed IE7 issue with submenu headers in plain menus not stretching to the largest width; fixed IE7 issue with deeper menu levels in sliding menus having an indentation; added styling rules to make the root node of ace:menu display like a block element, as before (and without stretching the menu contents).

r44292: removed extra padding and margins from ul element in all menus; added distinctive class name to root node of ace:menuButton (in 3.3 EE maintenance branch).

Marking as fixed. Verified all styling changes in the 4.0 trunk and in the 3.3 EE maintenance branch. The only issue that couldn't be fixed is with the tiered ace:menu on IE7 (3.3 EE maintenance branch). The left arrow icon appears next to the label, instead of appearing at the right edge. Functionality is still normal.

While working on this JIRA, an issue with sliding menus was found, which could be reproduced before these styling changes. It is described in ICE-10600.

Verified no additional issues (besides ICE-10600) found. ICEfaces EE-3.3.0 maintenance branch r44364, ICEfaces EE-4.0.0 Jenkins build 5. Tomcat 7, IE 11, FF 34, Chrome 41.