Arran, is the workaround I proposed functional for you? I re-tested and it works well on my machine.

It is functional only with the standard JSF components. When using the same ICE compat components I still see the issue. I just checked and I also changed the h:outputText on test2.xhtml to an ice:outputText, the zip attachment should have this code change.

Defined icefaces-compat.js and compat.js resources as dependencies for ice:outputText component. This ensures that whenever an ice:* component is used the basic set of resources are loaded and thus full document updates are avoided during forward navigation.

Thanks Mircea for this fix. I just tested the code and it looks good for the ice:commandButton forward to an ice:outputText scenario.

It is still crashing for an ice:commanButton to h:outputText scenario. Here is the code used:

test.xhtml

<h:body >
<div id="an-id">
<h:form id="form" >
<ice:commandButton value="Set attribs"
action="/test2.jsf"></ice:commandButton>
</h:form>
</div>
</h:body>

test2.xhtml

<h:body>
<div id="an-id">
<h:outputText value="#

" escape="false" />
</div>
</h:body>

Well, the last commit was not made to fix a problem but more for convenience, to avoid running in this corner case. The reason why you still see the crash is due once again to the update of the entire 'body' element in the page. This makes IE crash. When you navigate from one page that has ice:* components to one that doesn't an update is generated for the 'head' element to remove icefaces-compat.js and compat.js resources (same thing happened for ice:outputText which used to not require the compat resources). A 'head' element update will in turn trigger an update for the entire document, but in 3.3 we send only the update for the 'body' and optionally a separate update for the 'head'.
In conclusion I cannot fix this issue entirely, you (or the client) will have to setup the pages to avoid generating 'body' element updates. This might mean inserting ice:* components in the destination page just to avoid the changing the list of referenced resources in the 'head'. Defining mandatory resources would be another workaround.