Attached is a test case that can reproduce the issue. Its not the best test case but following the steps you can see the issue. Steps to reproduce issue:

• Load app, notice that there are three menu items in the menubar.
• Click on the button, this should reinitialize the menubar model. It does in the backing bean but the UI isn't updated.
• Click on the browser refesh button.
• This should now show the three items. Clicking on each item will show a JavaScript alert.
• Click on the update button. Now try clicking on the menu items. The JavaScript alert is no longer there since the custom on click code has not been added again.

Reminder to retest this using the BETA release code to ensure it's still present.

I'm of the opinion that there might be two separate issues here:

1) The UI does not update from 3 -> 4 menu items when clicking the "Update" button. I can see the backing bean code being called but, as noted, the change is not reflected in the UI unless you reload the page. Looking at the response that comes back to the browser, I don't see any updates other than the ViewState:

<partial-response>
<changes>
<update id="javax.faces.ViewState">1438841264988732930:7469407961588975733</update>
<extension aceCallbackParam="validationFailed">

</extension>
</changes>
</partial-response>

This may indicate that the dynamic menu additions are somehow not being reflected in the DOM and therefore not detected as part of the DOM diff.

2) The attached JS alerts are no longer displayed. This behaviour changes when the TestBean is changed from SessionScoped (which it is currently) to ViewScoped. When I change it to ViewScoped, the menu always has 3 items (as the update problem noted in point #1 above is still an issue), but the JS alert code is always functional.

Fixed at revision 25810...

Originally, the component didn't support modifications to the menu when building from model. The menu only was built at the beginning and it wasn't possible to update it. Code was added to remove this condition and re-build the menu at every request if its 'model' property is not null. However, this change caused a problem with having duplicate id's since the previous generated children of the menu weren't being removed before re-creating the menu. This was temporarily solved by calling getchildren().removeAll(getChildren()) from the AbstractMenu class before the new children were added. However, it was later found out that the UIComponentBase class subclasses the java.util.ArrayList class used to keep the list of children and adds some custom logic. This was causing, in some cases, the same problem with the duplicate id's since not all children were being removed. Eventually, this was solved by calling instead getChildren().clear(), which directly removes all contents of the list without any custom evaluations.

We assigned id's to all of our submenus and now, when the ace:menubar is dynamically updated, the submenu values are not displayed, only the image is there.

Update the poc, in the first submenu you should find a selection for print that will dynamically add a print menuitem. Afterwards, you will see the submenu value(label) disappear.

This has been fixed by a preliminary generator change related to ICE-7321. The new approach will be improved, but the basic idea seems to fix this particular problem.