Attached test case that shows this issue. Note: the icefaces.jar, icefaces-compat.jar and icefaces-ace.jar files need to be added into the war to show this issue.

Steps:

• Load welcomeICEfaces.jsf
• In the input text field, add some values.
• Without tabbing out of the field, click one of the commandButtons.
• The expected behavior is that the navigation executed by the buttons is done. The issue is that the input field is submitted, but the button click action is not called.

Not clear why this issue is appearing again. This was resolved originally in ICE-4308 for EE 1.8.

I cannot reproduce this issue. I did follow exactly the test instructions.

I went back and re-tested my sample. In Firefox, IE, and Chrome I see this issue. When ever the input field has focus and you click a button, the button action is not fired. It takes two clicks to get the buttons to work. I am testing with the current maintenance branch jars if that matters.

Once again I cannot reproduce this issue. Tested with all mentioned browser with successful results. There must be something else, maybe your environment, that makes this issue occur on your machine.

Tested with ICEfaces EE-3.3.0 maintenance branch r45992 using attached test case, IE 11, FF 34, Chrome 45. I am able to confirm Arran's findings.
If the input field has focus, the very first button click (does not matter which button) does not cause the navigation to occur. In the server log the text entered into the input is set but the navigation does not happen. A second press of the button is required.

The issue will occur only if the textarea's content was changed before clicking on the 'Page 2' button. In this use case the textarea will issue a singleSubmit on the 'change' event, the subsequent submit triggered by the 'click' event on the button is blocked by the blockUIOnSubmit feature. Since the submit that reaches the server is not triggered by the button the navigation is also not triggered.
The obvious fix would be to modify the single submit capturing to not issue the submit on 'change' events (and actually we do that already for IE browsers). Now there might be other use cases where 'change' triggered submits are relied upon.

A work around for this particular issue is maybe a better approach. To do that the 'change' events for textarea should be canceled and thus allowing the 'click' event from the button to go out. Only the page in the test application needs to be changed or that to:

...
<ice:inputTextarea id="freeform" value="#{testBean.text}" onchange="if (event.stopPropagation) { event.stopPropagation() } else { event.returnValue = false; }"/>
...

Tested with ICEfaces EE-3.3.0 maintenance branch r46929. Verified work-around using test case and Tomcat 8, IE 11, 10, 9, 8, 7, FF 43, Chrome 47.