Attached test case to reproduce issue.

Steps:

• Load welcomeICEfaces.jsf
• Click on the Delete button for the first row.
• The confirmation dialog is shown, click on the Yes button.
• The first row is removed.
• Click on the Delete button for the new first row.
• The dialog is displayed for an instance.
• Clicking on the Delete button again shows it completely.

This problem can be easily avoided by appending "return false;" at the end of the onclick attribute of the h:commandButton used to display the dialog. This situation no longer happens if using the latest build.

The problem occurred in the test app because the h:commandButton used to display the dialog was making a submit (as is normal) and thus the server was sending a response with an update for the whole table, so the original HTML elements used to display the dialog the first time were immediately replaced. With "return false;", no submit is made to the server and thus there are no updates to apply while the dialog is showing.

Now, even without using "return false;" in the onclick attribute of the button, ideally there shouldn't be an update of the whole table if the user didn't directly changed the state of the application. I analyzed the response and I noticed that there's this node '<div style="display:none;">2</div>' at the very end of the table markup, which seems to increase at every request. This is the only thing that changes in the markup when clicking the button to display the dialog. Since, this node doesn't have its own client id, then the parent element (root node of the table component) has to be updated, and thus the whole table markup is updated and the original dialog nodes disappear. In the latest build this is no longer the case, so these unnecessary updates do not take place any more.

The only situation where something like this can still occur is when the first page of the application that is loaded by the user is this page (thus starting a new session) and the server has to use the jsessionid parameter in the url. Then, when this parameter is no longer necessary, the url of the containing form will change, triggering an update for the whole form. However, this is avoided by simply using "return false;", as explained above.