Autocomplete component is using single submit requests to acquire the list of choices. The single submit function is cloning the node that does the submit and puts into a separate form used for submission. When running with Mojarra the cleanup code for the cloned elements is ran right away while with Myfaces the code is executed in only after the updates are applied (see http://jira.icesoft.org/browse/ICE-7562?focusedCommentId=37621&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-37621 ) . Since the submit is blocked by the client validation the after update callbacks (including the cleanup callback for the cloned elements) are not executed, hence the duplicate element that sticks around.

Removed cloned element Myfaces specific code, run the code used for Mojarra instead. It seems the Myfaces brought the form serialization behaviour inline with the one found in Mojarra.

Verified ICEfaces 4 trunk r48844. Tomcat 8, IE edge, 11, 10, FF 43, Chrome 50.
There are still issues when testing this scenario with IE 8 and 9.
Use test page /autoCompleteEntryClientValidateLength.jsf from:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/autoCompleteEntry

IE 9 - Enter a character into the autoCompleteEntry, the character is immediately removed. (mojarra and myfaces). After performing a submit on the page the behaviour returns to normal.
IE 8 - After entering input into the autoCompleteEntry, then selecting an option from the list a js popup error is seen (myfaces only):
Message: Unspecified error.
Line: 27
Char: 77
Code: 0
URI: http://10.18.39.134:8080/autoCompleteEntry/javax.faces.resource/autocompleteentry/autocompleteentry.c.js.jsf?ln=icefaces.ace&v=4_2_0_160524

Modified ice.singleSubmit function to remove inline scripts contained by the cloned element and thus avoid their execution in IE when inserted into the document. This fixes the immediate removal of the input character.

I cannot reproduce the Unspecified error error. What are the exact steps for reproducing it?

Tested with ICEfaces 4 trunk r48859.
The fix committed at r48856 Jenkins build 1996 causes the options list to no longer drop down after typing a letter into the autoCompleteEntry. This occurs when the autoCompleteEntry is not using ajax. This issue can be demonstrated in the QA autoCompleteEntry test apps such as autoCompleteEntry Only, in dataTable.. etc.
This can also be seen in showcase autoCompleteEntry > Overview, Select Items, Custom Facet , Match Criteria, etc when built with myfaces libs. Does not affect showcase built with mojarra libs.
This issue was not present in the previous Jenkins build 1995.

Modified singleSubmit function to test for null items when iterating through the script nodes (IE can return null items in the node list).

In autoCompleteEntry test, fixed the path used for looking up the resource that contains the city list.

Tested with ICEfaces 4 trunk r48863.The following issues still remain:
1.) IE 8 -Entering input into the autoCompleteEntry after a clientValidator was invoked , then selecting an option from the list, a js popup error is seen (myfaces only):
Message: Unspecified error.
Line: 27
Char: 77
Code: 0
URI: http://10.18.39.134:8080/autoCompleteEntry/javax.faces.resource/autocompleteentry/autocompleteentry.c.js.jsf?ln=icefaces.ace&v=4_2_0_160524.

To reproduce this issue

• Build the QA autoCompleteEntry with myfaces.
• Use with ie8 on icepcvm-ie8.
• Navigate to this page - ICE-10819 - ace:autoCompleteEntry with ace:clientValidateLength
• In the autoCompleteEntry at the top of the page, enter 3 letters such as sas in order to make the list appear.
• Choose an item from the list, the js popup error appears.

2.) IE 9 - Enter a character into the autoCompleteEntry, the character is immediately removed.
To reproduce this issue

• Build the QA autoCompleteEntry with mojarra or myfaces.
• Use with ie9 on icepcvm-ie9.
• Navigate to this page - ICE-10819 - ace:autoCompleteEntry with ace:clientValidateLength
• Type letters into the first autoCompleteEntry, they are immediately removed.

Applied fix for IE8 issue that modifies the onFocus callback to avoid invoking TextRange.select() since no range selection is defined. The callback intent is just to move the cursor at the end of the text (which it still does).

Tested with ICEfaces 4 trunk r48876. The commit at 48876 has fixed the IE8 js popup issue however it has caused some regressions in clientValidators that do not use a min length attribute.
example:
In the QA test app autoCompleteEntry with ace:clientValidateLength, the second autoCompleteEntry on the page uses the max attribute. When you insert the cursor and type, the cursor is moved to the front of the autoCompleteEntry. This is an issue with both mojarra and myfaces libs.

The third autoCompleteEntry on that page uses both min and max attributes. The cursor moves forward when typing until the min has been achieved. At that point it moves back to the front of the autoCompleteEntry.

The incorrect cursor placement can also be seen in any of the ace:autoCompleteEntry clientValidator test apps that do not use the length min attribute, such as validate pattern, required etc.

This is not an issue with the later versions of IE such as 10 and 11. Can not test with IE 9 as the "character removed" issue remains.

Added back the TextRange.select call to undo the regression described above. ICE-11035. Added try/catch block around the TextRange.select call, the call seems to be effective even when it throws the "Unspecified error".

The IE 9 issue fails with 4.1.0 release libs. Showcase demos pass with current code. The difference is the showcase demos do not use ajax in the clientValidators.

1) Expanded try/catch block around input element's function calls.

2) The cursor is moved because the input element does not keep its cursor state when is updated in IE8/9. This is an old issue that was worked around with some IE custom code to move back the focus were it was previous to the update application.

Tested with ICEfaces 4 trunk r48882. The ie8 js popup error is now resolved.
When testing with IE 9 where there is a clientValidateRequired the input is still removed when typing into the autoCompleteEntry.

Removed old reset code in updateField function to avoid interference with client validation in IE9.

ACE reset functionality should be retested with autoCompleEntry to make sure no regressions were created.

Tested with ICEfaces 4 trunk r48888. autoCompleteEntry tests fail with ie9 and myfaces libs. After selecting an item from the list then backspacing in the autoCompleteEntry, the letters are removed then rendered again.

To reproduce:
1.) Build app with myfaces libs. and open with ie9
2.) Use the autoCompleteEntryOnly test.
3.) Type the letter a, then choose an item from the list
4.) Press the backspace key. Notice that the last letter was removed but renders again when the list updates.

Is this a regression?!

No need. I just wanted to know if I'm making any advance in fixing the known issues.

The issue with IE 9 where input was removed when typing into an autoCompleteEntry with clientValidateRequired is resolved.
The IE 8 js popup error is resolved.

ICEfaces EE-4.1.0.GA Jenkins build 2 - Verified fixes to date.

Changed element cloning implementation in ice.singleSubmit function to make sure no script element is cloned and thus evaluated by IE9.

Verified remaining ie9 + myfaces issues resolved. ICEfaces 4 trunk r48917.

Verified ICEfaces EE-4.1.0.GA Jenkins build 4. myfaces libs, tomcat 8, IE 11, 9, 8, FF 43, Chrome 50.