can you please confirm whether it occurs without ICEfaces (just jsf2.0)?

Problem could not be reproduced without icefaces.

Test-case is available at "repo\qa\trunk\Regression-Icefaces2\ICE-5988".

note Mandeep's comments, but looks like a problem with ICEfaces-2 only

I don't have IE6 currently installed but I did try this with Chrome (where it worked) and Firefox (where it had some problems).

With Firefox, after I entered some text and hit enter, the Firebug console would complain about the update causing too much recursion:

too much recursion
//]]>]]><![CDATA[
main.jsf (line 4)

The update itself looks something like this and the problem seems to revolve around the extra nested CDATA about 2/3 of the way down. It's easy enough to recreate with Firefox.

<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="debugPanel"><Unable to render embedded object: File ([CDATA[<span id="debugPanel"><script language="javascript" type="text/javascript">//<) not found.[CDATA[
function faceletsDebug(URL)

;var faceletsOrigKeyup = document.onkeyup; document.onkeyup = function(e)

;
//]]>]]><![CDATA[
</script></span>]]></update><update id="iceform:output1"><Unable to render embedded object: File (output1">Input: abbbbbb</span>]]></update><update id="javax.faces.ViewState"><) not found.[CDATA[-1425665775163257041:-4653656636132828859]]></update></changes></partial-response>

A screenshot of Firefox + Firebug showing the problem of too much recursion when UIDebug is being rendered.

Still testing but it looks like the update to the UIDebug component is a little haywire for some reason. We did do some work to wrap this in a span (http://jira.icefaces.org/browse/ICE-5717) to help facilitate updates but maybe there's something not working quite right with that.

Looks to me like the issue is related to some CDATA massaging that we do in DomUtils.printNode() - specifically:

case Node.TEXT_NODE:
if (!isInCdata)

else

break;

I'm not sure that the replaceAll section is supposed to accomplish in our own code but with the script that's generated by the UIDebug component, it causing then end of the script be changed from:

; else if (faceletsOrigKeyup) faceletsOrigKeyup(e); };
//]]>

to

; else if (faceletsOrigKeyup) faceletsOrigKeyup(e); };
//]]>]]><![CDATA[

which leads to the JavaScript processor to complain. They likely all complain in different ways - IE6 doesn't handle it well and just recurses right out of memory.

"Massaging" introduced in this JIRA:

http://jira.icefaces.org/browse/ICE-5742

The fix was specifically for ui:debug (and verified at that time) , so perhaps it is being exercised under different conditions.

Removing the printNode ]]> escaping code results in the original XML parsing errors seen in ICE-5472. This indicates that the fix is working correctly (well-formed XML is being generated even when CDATA sections are included in the HTML), however some other code in jsf.js may not be reacting correctly.

Issue still present with mojarra jsf-api-2.0.4-b03.jar jsf-impl-2.0.4-b03.jar.

This appears to be a bug in the the Facelet debug JavaScript – it does not allow itself to be registered multiple times:

Extracting the relevant parts:

var faceletsOrigKeyup = document.onkeyup;
document.onkeyup = function(e)

;

Removing

else if (faceletsOrigKeyup) faceletsOrigKeyup(e);

disables the onKeyUp chain recursion, however, also destroys any third party onKeyUp behavior.

Placing ui:debug in the HEAD does not serve as a workaround – the contents of the script are updated each time (facelets.ui.DebugOutput=1281978479087) resulting in an update to the node and recursive addition of the script. Perhaps ui:debug can be modified to be included in jsf.js and search the document (or suitable container) for the ViewState key. Note that ui:debug will not work correctly in the Portlet case due to the global registration of the DebugOutput ID.

One short-term solution for mojarra would be to not register a new onKeyUp handler if a debug handler is already registered (also stored in a global variable). However, this would not address the Portlet case, where the debug element should probably add onKeyUp to just the parent container.

Assigning to Mircea for comment and suggestions (I'm not sure whether the mojarra would will be most interested in a short-term fix or a Portlet solution). It should be possible to reproduce this bug in mojarra by altering the test case to always update the element containing the ui:debug via Ajax.

Re-assigning to Mircea for re-evaluation of the synchronized Ajax request on disposal before the final release.

Created test case that replicates the issue in JSF only environment (no ICEfaces). Created issue in Mojarra's bug tracking system: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1855 . Attached the test case to the issue.

In lieu of waiting for Mojarra to fix this issue someday, we could also create a replacement ui:debug feature for ICEfaces.

Waiting for Mojarra fix.