Attached test case that shows the issue.

Steps:

• Load welcomeiCEfaces.jsf
• Enter in some text to the input field.
• Click the Open button.
• Close the popup with the 'X' button.
• Try adding more text or opening the popup again, nothing happens.

Note: I did notice that the very first time testing this in a fresh browser instance that it does work but the second try does not.

I'm not sure that the tabindex is the root of the problem. I can see the tabindex on the input element return to 0 from -1 after the modal popup is dismissed. I can also reproduce the issue within one form, so I don't believe you need multiple forms to see the problem. It only seems to occur in conjunction with an ajax push update, or at least I can only reproduce it in the attached test case with an ajax push call. The customer contends that they also see it with non-ajax push interactions, although they agree it's more frequent with ajax push.

Marked panel popup's root element for server-side onElementUpdate notifications. Also, modified form renderer to use setRootElementId method which makes sure to mark the "id" attribute as the one for looking up the element. This way the onElementUpdate feature can find the updated region. Introduced DOMContext.enableOnElementUpdateNotify utility function for marking the elements.

It seems that the test case, when using ajax push to open the popup still fails. See attached simplified test case, ICE9323.war.

steps to reproduce:
1. go to /ICE9323/index.jsf
2. type in a few letters in the input field
3. click on 'Open Popup'
4. click on 'Close Popup'
5. try to type something in the input field

The input field at this time will not accept any input. There are several keys to configuration for this bug:

• blockUIOnSubmit must be true
• the popup must be activated by an ajax push
• the resulting DOM update from the ajax push must not include the content for the input field

It looks to me like the ice:panelPopup's modal code and the blockUIOnSubmit modal code are interfering with each other. With two modal mechanisms trying to restore key listeners, it's very possible that one saves and restores the temporary blocking listeners setup by the other.

This could be alright:
A.block : Save away real listeners into A.real, and wire in A.fakeNOOP
B.block : Save away A.fakeNOOP listeners that we thought were real into B.real', and wire in B.fakeNOOP
B.unblock : Remove B.fakeNOOP listeners and restore B.real'
A.unblock : Remove A.fakeNOOP listeners and restore A.real

This would be broken:
A.block : Save away real listeners into A.real, and wire in A.fakeNOOP
B.block : Save away A.fakeNOOP listeners that we thought were real into B.real', and wire in B.fakeNOOP
A.unblock : Remove A.fakeNOOP listeners and restore A.real
B.unblock : Remove B.fakeNOOP (the real ones!) listeners and restore B.real' (fake NOOP ones!)

Let's look at "the resulting DOM update from the ajax push must not include the content for the input field". blockUIOnSubmit does the block onBeforeSubmit and the unblock onAfterUpdate, so an ice.panelPopup call to Ice.modal.start is likely between that, so Ice.modal.start will save away fake NOOP event handlers setup by blockUIOnSubmit, and when Ice.modal.stop is called, it will restore those, thereby breaking the elements. If the update had included fresh elements, the Ice.modal.start would have been saving the fresh new valid listeners instead of the fake ones, and so would restore real ones.

If we put the Ice.modal.start call inside of a setTimeout, that will make it be called after onAfterUpdate, then possibly that would fix things.

Although, we'd need to think of the timing for calling Ice.modal.stop in relation to the dialog close lifecycle, which itself will do another round of blockUIOnSubmit. In that case, blockUIOnSubmit will then save away the fake handlers setup by Ice.modal.start, and restore them in onAfterUpdate, so our call to Ice.modal.stop needs to happen after that as well. Meaning we need to both render out Ice.modal.stop in a setTimeout, and render our ice.OnElementUpdate to call a setTimeout that then calls Ice.modal.stop.

Enable input element callbacks on before update instead of after update. This way the interference with ice:panelPopup who also is disabling and enabling the callbacks is avoided. Mark has already described correctly what is going on.

Verified using ICEfaces-EE build 14 in Firefox21: no issues found using 'Case12185Example' test case.
When using 'ICE9323' test case, user must click twice to open popup, but no other issues have been found.

Re-opened. 2nd test case is failing now. Mircea, please verify with both tests.

Resolved. Both tests are passing now, ICE-9323 test was missing the icepush-ee.jar in the war.