Forum user found that having an inputRichText component in the same form as a fileEntry causes the fileEntry not to work.

After investigation, I can see that inputRichText with saveOnSubmit="true" does interfere with the form onsubmit mechanism that fileEntry relies upon.

In Firebug, I can see this for the form:

<form onsubmit="return false;" action="javascript:;" .../>

Which would definitely mess things up. As well, in the Javascript, I've found the offending code that stomps over the onsubmit:

icefaces2/compat/components/src/main/java/com/icesoft/faces/component/inputrichtext/fckeditor_ext.js
Lines 139 - 157

function FCKeditor_OnComplete(editorInstance) {
    var onCompleteInvoked = Ice.Prototype.$(editorInstance.Name + 'onCompleteInvoked');
    var fieldWithClientId = Ice.Prototype.$(editorInstance.Name);
    if (fieldWithClientId) {
        fieldWithClientId["jsInstance"] = editorInstance;
    }
    if (onCompleteInvoked)onCompleteInvoked.value = true;
    Ice.FCKeditorUtility.updateValue(editorInstance.Name);
    editorInstance.LinkedField.form.onsubmit = function() {
        return FCKeditorSave(editorInstance);
    }
    if (fieldWithClientId["AppfocusRequested"]) {
        try {
            editorInstance.Focus();
        } catch (e) {
            logger.info(e);
        }
    }
}

The FCKeditorSave(-) function basically does an iceSubmit(form, element, new Object()); and then returns false, to disable the browser's submit.

Most of the rest of the code seems to be involved in updating a hidden input field from other javascript event, likely so that any other ICEfaces partial or full XHR submit will have the correct value. This part or doing an iceSubmit, and returning false, seems unnecessary in any context. Maybe there's some edge case, or we just assumed it would be better to AJAXify the response. It would also stomp over our regular non-fileEntry onsubmit interception, but does something similar, so maybe that's why we haven't noticed.