JSF ajax event queue doesn't work on action-event after change-event

The JSF AJAX calls are asynchronous. Sending one AJAX request, in this case generated by <h:inputText> onchange event, doesn't stop JavaScipt to continue its execution and, in this case, trigger submit button click, which in its turn fires another AJAX request. Still, AJAX requests are really queued on the client, to be processed in the exact order that they were sent, which is guranteed by JSF 2.0 specification, chapter 13.3.2.

Below is my test case:

The view:

<h:form id="form">    <h:inputText id="text" value="#{q16363737Bean.text1}">        <f:ajax render="text2" event="change" listener="#{q16363737Bean.ajaxListenerText}"/>    </h:inputText>    <h:commandButton id="button" action="#{q16363737Bean.actionButton}" value="Submit">        <f:ajax render="text1 text3" listener="#{q16363737Bean.ajaxListenerButton}"/>    </h:commandButton>    <br/>    <h:outputText id="text1" value="Text 1: #{q16363737Bean.text1}."/>    <h:outputText id="text2" value="Text 2: #{q16363737Bean.text2}."/>    <h:outputText id="text3" value="Text 3: #{q16363737Bean.text3}."/></h:form>

The bean:

@ManagedBean@ViewScopedpublic class Q16363737Bean implements Serializable {    private String text1 = "I'm text 1";//getter + setter    private String text2 = "I'm text 2";//getter + setter    private String text3 = "I'm text 3";//getter + setter    public void ajaxListenerText(AjaxBehaviorEvent abe) {        text2 = "I was modified after inputText AJAX call";    }    public void ajaxListenerButton(AjaxBehaviorEvent abe) {        text1 = "I was modified after AJAX listener call of commandButton";    }    public void actionButton() {        text3 = "I was modified after commandButton AJAX call";    }}

After examining the question for some time I indeed figured out that very rarely the command button's AJAX call had been swallowed and no UI updates were done. It seems that there should be some race conditions somewhere. It is a great question and it needs to be investigated further.

So, this is probably not an answer (although I thought it would be initially), but a proposition for a test case. And despite the fact that I faced this behaviour very infrequently, it is a real use case, and it's worth fully understanding what's going on.

First thanks allot for the fast and sophisticated reply.

A second test from the scratch pointed out that ajax-events are queued properly.

So again I checked the more complex scenario described above. The cause for the skipped event seams to be related to our 'busy overlay'. Think of it as a bunch of JavaScript which disables form-elements and applies an overlay during long runing ajax requests. This is done by applying an jsf.ajax.addOnEvent call-back.

Anyway, even we disable some controls, after 'success' the form is in a proper state and the second event could be handled.

Currently I assume that the 'temporarily' disabled button compromises the related action event which should be carried out afterwards.

We are currently analyzing the issue and I will post the final result asap.