Attached test case that shows issue. Steps:

• Load welcomeICEfaces.jsf
• Enter in some text to the maskedEntry.
• Click the Enter key.
• The outputText gets updated but the listener for the ace:ajax tag isn't called (See server logs).

Need to review behavior to ensure that all ace:*Entry components have consistent behavior in terms of when valueChange events are fired. May also need to add "textChanged" ace:ajax events also for cases when they want to trigger an event for each key press instead of using valueChanged.

An analysis of the ACE text entry components was made to understand how they behave and what behaviors they have in common. The following is a summary of the findings.

First, the ace:maskedEntry component was compared to the standard h:inputText component. It was found that they have the exact same behavior when it comes to the valueChange event (either via an ajax tag or via the valueChangeListener attribute). This is how they behave with different configurations:

• When h:inputText has an f:ajax tag for the valueChange event with a listener AND a valueChangeListener attribute defined, and when ace:maskedEntry has an ace:ajax tag for the valueChange event with a listener AND a valueChangeListener attribute defined as well.
  -> When tabbing out or clicking outside the text field, an ajax behavior request is made and both the ajax listener and the valueChangeListener method are fired.
  -> When pressing enter, an ice.s request is made and only the valueChangeListener method is fired.

Note that when pressing enter, a full submit is made by the bridge, not by the component itself. This is an ice.s request, and it doesn't contain the necessary request parameters for the ajax behavior to be triggered.

• When h:inputText and ace:maskedEntry only have a valueChangeListener attribute defined.
  -> When tabbing out or clicking outside the text field, no request to the server is made whatsoever.
  -> when pressing enter, request is made (bridge), listener is fired

• When h:inputText has an f:ajax tag for the valueChange event with a listener, and when ace:maskedEntry has an ace:ajax tag for the valueChange event with a listener.
  -> When tabbing out or clicking outside the text field, an ajax behavior request is made, firing the ajax behavior listener.
  -> when pressing enter: a request is made by the bridge, but the ajax behavior listener isn't fired.

So, it could be said that the intention of pressing enter is to make full submits, since that also happens with plain input text HTML elements. Also, we can say that the valueChange event is not so ajaxified.

Other components behave in similar ways.

ace:textEntry

• It doesn't have an ace:ajax valueChange event.
• with valueChangeListener shows the same behavior as h:inputText and ace:maskedEntry.

ace:textAreaEntry

• It doesn't have an ace:ajax valueChange event.
• Same behavior as ace:textEntry, except that pressing enter doesn't initiate a request (it simply moves to the next line in the text area).

ace:autoCompleteEntry

• It doesn't have an ace:ajax valueChange event.
• With valueChangeListener, it fires the method at every keypress, even up/down arrows. It doesn't fire when tabbing out or clicking outside, since the change in value was already registered at the key press event.

ace:richTextEntry

• It doesn't have an ace:ajax valueChange event.
• The tab and enter keys are trapped by the CKEditor, so no requests are made when pressing them.
• Clicking outside the editor doesn't initiate any request either.
• The valueChangeListener method is only fired when pressing the 'Save' button (if the value actually changed).

Some observations/conclusions:

• For ace:autoCompleteEntry, it would make more sense to have a textChange event, which would be separate from the valueChange event, as described in ICE-8876.
• We could also add a textChange event to the other components, which would work in exactly the same way. From the component perspective, we could think of it as a secondary value property that registers the change, but it's not the definite value property.
• Returning to the original issue of this JIRA. Perhaps in the case of ACE components we can let the components handle the enter key press themselves, instead of letting the bridge initiate full submits, to allow sending ace:ajax requests?

A practical solution for this customer, based on the test case, would be to also define a valueChangeListener attribute in the component tag, whose only job would simply be to invoke the method defined in the ace:ajax tag (or create a separate method that both listener methods would invoke).

Committed fix to the trunk at revision 33036.

When the component has a valueChange ajax event, if the user presses the ENTER key, a behavior request will be submitted (instead of the full ice.s submit), which will fire the listener method. This request will be made whenever ENTER is pressed, even if the value didn't actually change.