Attached test case that shows this issue. Note: the icefaces core, ace, and compat jar files need to be added back into the war for it to run.

Steps:

• Load welcomeICEfaces.jsf
• A singe menuBar is displayed, hovering over this menuBar/item shows the hover CSS, etc.
• Click on the "Chaneg Menu Item Text" button, the menuItem text is changed but the CSS is no longer displayed and it does change in size.

Additionally with my sample I have a larger more complex MenuModel setup that shows that this only happens when the menuItem is the first item in a menuBar. If a submenu is used, then this isn't an issue. To see this, change the rendered flag on the first form in the welcomeICEfaces.xhtml page.

This is not really a bug. It's just the way things work internally. What actually happens is that when the menu item label is changed, because it has its own client id, only the menu item markup is updated on the page, without reapplying the extra styling and nodes added by the Wijmo Menu widget, namely the extra span and the wijmo-wijmenu-link CSS class on the <a> element, as well as the hover and active styling, etc. The component is always rendered the same way from the server on the first load and after updating the label, so nothing is lost, it's just that the extra nodes and styling aren't re-applied. To re-apply these nodes and styling, it would be necessary to force an update of the whole menu. This is the reason why this issue is not seen in the more complex, larger menu model: because a submenu label is also updated at the same time, and since this submenu doesn't have its own client id, the whole menu is updated. In the past, I had removed the client id from menu items to prevent this kind of issues, but this was causing some other issues with the bridge and domdiff, so it was re-added.

A practical solution, is illustrated in the attached xhtml document, which contains a slight modification of the xhtml document in the attached test app. It consists of placing the menu inside an h:panelGroup, and inside that same group, adding plan a <span> element with style="display:none;" and rendering the item label inside of it as well. It won't be visible to the user, and since this span will be changing its content at the same time as the menu item label, and because it doesn't have its own client id, it will force the entire panel group (containing the menu) to be completely updated, and this way all the extra nodes and styling are re-applyied by the Wijmo Menu library after the update. One of these <span>'s would have to be added for each menu item label that changes.

A more elaborate fix would consist in computing hashcodes for all menu items in a menu, and then computing a hashcode of all those hashcodes and render it on the menu's root container to force a full update, whenever something changes in the child menu items.

Committed fix to 4.0 trunk at revision 43548 and to 3.3 EE maintenance branch at revision 43549.

Added the 'forceMenuUpdate' attribute to menu components (ace:menu, ace:menuBar, ace:contextMenu, and ace:menuButton) to avoid this kind of issues. When, this attribute is dynamically set to true in a listener method or if its expression evaluates to true, the whole menu will be updated in the client, ensuring that all the required styling and behaviour is re-applied in the client side to the new nodes. Immediately after consuming this attribute, it will be automatically set back to false by the component itself (if applicable).

Testing notes: to test this feature, it will be necessary to create new test pages for all the menu components. The test could be similar to the attached test app, and it should dynamically modify a menu item at the same time it sets to true the 'forceMenuUpdate' attribute. The test will pass if the menu maintains it's styling and behaviour for the menu item that was dynamically modified.

Added 'forceMenuUpdate' tests for ace:menu, ace:menuBar, ace:contextMenu, located for ICEfaces4 trunk here:

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

Test page: /ICE-10203.jsf

The forceMenuUpdate attribute is set to true whenever the menu item label text is updated (when the "Change Menu Item Text" button is clicked), then the attribute is automatically set to false by the component when the menu* component is reinitialized in the browser.
This attribute appears to work as expected when the menu* component is rebuilt from a model.
The simpler test replicating the attached test app still doesn't appear to work:

• deploy any of the menu/menuBar/contextMenu apps.
• load /ICE-10203.jsf
• click on the "Change Menu Item Text" button.
  Expected: hovering over the menuBar/item shows the hover CSS.
  Actual: the menu item text has changed but the CSS is not displayed.

I committed a fix to the test app: added a forceMenuUpdate property in TestBean, since the app was trying to set such property in a new instance of AttributeBean, which wasn't a managed property.

Now the test works. The test that loads from a model also work correctly. The only interesting thing is that each of the load buttons only sets forceMenuUpdate to true for only one of the menus, so the one that doesn't get its forceMenuUpdate property to true loses its styling, as expected. Perhaps this was made on purpose to see the difference? Anyway, if both forceMenuUpdate properties were set to true in the load buttons' action listeners, both menus would keep all their styling.

All other QA test apps have been corrected.
Verified with IF4 trunk/EE-3.3-maintenance r43636 in IE10, FF34, Chrome39.