This is also reproducible with EE-3.3.0-maintenance branch r. 43351.

Fixed issue by disabling the behaviour of automatically updating the underlying textarea when the form is submitted in the CKEditor code.

Committed fix for ice:inputRichText at revision 43605, for ace:richTextEntry at revision 43606, and for ace:richTextEntry in the 4.0 trunk at revision 43607.

EE-3.3-maintenance r43607/ IE10, Chrome39, FF33:
Testing ice:inputRichText with Save on Submit disabled is resolved now, no changes are shown until the Save button is clicked.
However if Save on Submit is enabled, the text updates in the Rich text component are rendered only if the Perform a Submit button is clicked twice for any change (all browsers).

The same behavior was found for ace:richTextEntry with saveOnSubmit=true (EE-3.3-maintenance and IF4 trunk r.43607): must click the Submit button twice to see the text changes rendered on page.
QA test application:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/richTextEntry
Test: /richTextEntryDynAttribute.jsf

Steps:

• on the /richTextEntryDynAttribute.jsf page, check the saveOnSubmit check box.
• type "some text" in the richTextEntry component, and click on Submit button.
  Expected: the entered text should be seen rendered on the page: Value:<p>some text</p>
  Actual: entered text is not rendered on page, until user clicks a second time on Submit button.

Committed fix to read the saveOnSubmit setting from within the CKEditor code, in order to keep the normal behaviour of automatically updating the textarea when submitting the form, so that submit buttons can be clicked immediately after leaving the editor, without having to first blur the editor to execute the update listener and then submit the form (revisions 43614, 43615, 43616).

EE-3.3-maintenance r43622: showcase > ice:inputRichText saveOnSubmit works as expected (IE10, Chrome39, FF33).

ace:richTextEntry: if saveOnSubmit=true, the value is updated on page only when clicking a second time on "save on Submit" button (IE10 and FF33 only; no such issue in Chrome39). This issue can be reproduced with the steps above using the ace:richTextEntry QA test app.

The last issue is not related to this fix, as it could be reproduced before, and it only happens the first time the form is submitted when dynamically changing an attribute in the ace:richTextEntry component, as in the dynamic attribute test page. After that, all subsequent form submissions update the value of the component correctly.

This seems to be an issue with the browsers themselves, for some reason they are unable to update the textarea value dynamically the first time the form is submitted, even though the CKEditor code to update it is correct and doesn't cause errors.

Since this issue appears to be an IE browser bug, and only occurs if you dynamically set the attribute (which is an unlikely scenario in a real-world app.), we'll consider this a known issue.

Resolved.