Reproduced the issue, and saw "try1" instead of the expected "try3".
Replaced the fileEntry with an h:inputText with required=true, and go "try3" as expected, showing that the issue is dependent on the fileEntry.
Added the fileEntry back in, along-side the h:inputText, and didn't select any files to upload at all, continuing to use the h:inputText validation. Got "try3" as expected", indicating that it's not the alternate ajax mechanisn used when a fileEntry is present, but rather something about how fileEntry validation affects the lifecycles.
Looked at the requests and responses. See that on try1 (valid fileEntry), we get back textarea display:none, script to render the editor, the file upload success message, and the clearFileSelection script. With try2 (invalid fileEntry) we get back the textarea display:none with no editor rendering script, the file upload failure message, and no clearFileSelection script. On try3 (valid fileEntry), "try3" is not actually sent but rather "try1" is, indicating that the lack of the editor rendering script in the invalid fileEntry lifecycle response is the root of the problem.
Note that fileEntry actually does its validation early be default due to backwards compatibility. Now setting immediateValidation="false". This actually worked. Interestingly, for try2 and try3, the rich text editor script came back in the dom diff but not the textarea. applyDomChanges explains the no textarea in response, and in theory if the rich text editor used validations phase to determine to render the script instead of render phase, that would explain the bad behaviour with fileEntry's default immediateValidation="true".
Verifying by ui:remove the fileEntry again and adding immediate=true on the h:inputText. Same problem, that the try2 response contained "try1", indicating some issue with the rich text editor not using a submittedValue, and no editor script, indicating it being decided to be rendered not in render phase but in validation phase.
So, this is not a fileEntry issue at all, but solely an ice:inputRichText issue with not functioning after another input component fails validation when having immediate="true", whereby validation happens in the decode phase.
Auditing of the InputRichTextEditor code showed that it was not using the typical rendering code that makes use of a converter and gives the submittedValue precedence over the value, but was instead only using the value, which means that submitted values would be discarded when validation fails, which supports the investigated behaviour.
Fixed InputRichTextEditor by making it make use of the proper UIInput utility rendering method. Verified with bot the fileEntry and inputText scenarios described above.
icefaces3 trunk
Subversion 34052