Attached test case that shows this issue.

Steps:

• Load welcomeICEfaces.jsf
• Focus into the input field and type in some text.
• Without moving focus, click on the commandLink. The listener is not called as per the server logs.
• Click the button again, the listener is called correctly.

I cannot reproduce the issue. The submits triggered by 'blur' and respectively 'click' events are both sent and the UI is blocked twice for each of them.

What do you see in the console logs?

I get the following testing my sample (added id's on the comps for better identification):

"[icefaces] [Thu, 28 Jan 2016 19:13:56 GMT] full submit to http://localhost:8084/Case13666Example2/welcomeICEfaces.jsf
javax.faces.execute: iceForm:inputEntry
javax.faces.render: iceForm:inputEntry
javax.faces.source: iceForm:inputEntry
view ID: v7z2kh4
event type: unknown" bridge-support.uncompressed.js.jsf:1817:89
[icefaces] [Thu, 28 Jan 2016 19:13:56 GMT] blocking UI bridge-support.uncompressed.js.jsf:1817:89
[icefaces] [Thu, 28 Jan 2016 19:13:56 GMT] persisted focus for element "iceForm:searchLink" bridge-support.uncompressed.js.jsf:1817:89
[icefaces] [Thu, 28 Jan 2016 19:13:56 GMT] unblocked UI bridge-support.uncompressed.js.jsf:1817:89
[icefaces] [Thu, 28 Jan 2016 19:13:56 GMT] applied updates >>
eval: //no changes were generated....
extension bridge-support.uncompressed.js.jsf:1817:89

This is what I get on Firefox:

2
[icefaces] [Thu, 28 Jan 2016 22:39:07 GMT] persisted focus for element "iceForm:_t6_input"
bridge-..._160126 (line 1817)
2
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] persisted focus for element "undefined"
bridge-..._160126 (line 1817)

[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] full submit to http://localhost:8080/Case13666Example2/welcomeICEfaces.jsf
javax.faces.execute: iceForm:_t6
javax.faces.render: iceForm:_t6
javax.faces.source: iceForm:_t6
view ID: vto7qup2
event type: unknown

bridge-..._160126 (line 1817)
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] blocking UI
bridge-..._160126 (line 1817)
POST http://localhost:8080/Case13666Example2/welcomeICEfaces.jsf
	
200 OK
		26ms	
jsf.js...._160126 (line 1886)
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] persisted focus for element "iceForm:_t7"
bridge-..._160126 (line 1817)
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] unblocked UI
bridge-..._160126 (line 1817)

[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] applied updates >>
eval: //no changes were generated....
extension

bridge-..._160126 (line 1817)
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] persisted focus for element "iceForm:_t7"
bridge-..._160126 (line 1817)
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] blocking UI
bridge-..._160126 (line 1817)
POST http://localhost:8080/Case13666Example2/welcomeICEfaces.jsf
	
200 OK
		47ms	
jsf.js...._160126 (line 1886)
[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] unblocked UI
bridge-..._160126 (line 1817)

[icefaces] [Thu, 28 Jan 2016 22:39:10 GMT] applied updates >>
eval: //no changes were generated....
update["j_id1:javax.faces.ViewState:0"]: -3813815393763133934:3494434207221328609....
eval: var iceFormIdList=['iceForm']; ice.fixVi....
extension

Are you able to reproduce the issue in IE? I'm not sure why you can't reproduce the issue using the same war file.

I am able to reproduce the issue in IE. It seems IE is slower in processing the response corresponding to the 'blur' triggered request and thus the next request triggered by 'click' event is blocked.

Now this is an issue we dealt with before ( ICE-10769 ) and determined that the blockUIOnSubmit feature does its job properly. I am not sure what kind of behaviour are we supposed to have here.

In order to exclude the textEntry from triggering blockUIOnSubmit and allow the 'click' event to trigger the submit the ace:submitMonitor component should be used instead of the global (per page) blockUIOnSubmit core feature. The ace:submitMonitor component allows one to limit the scope of the blockUIOnSubmit feature and thus workaround this issue.

Mircea Toma Your comment isn't absolutely true. Only by removing blockUIOnSubmit completely the ace:submitMonitor element with the attribute blockUI will work. If you have a lot of forms then it will take a lot of time to add an ace:submitMonitor element to every form. But this is due to a BUGFIX that should not have been made in my opinion: ICE-10518. The ace:submitMonitor element's attribute blockUI should be able to overwrite the blockUIOnSubmit setting. More of this argument can be found on this issue ICE-11454 and on this stackOverflow question.