Patch from ICE-8156 resolves the last of these issues.

According to ICE-8156, the following tests still show regressions when comparing Mojarra 2.1.6 to 2.1.9:

ICE-2113: A quick test shows that it's working fine when run on WebKit browsers (Safari and Chrome) but the popup panel is displaying blank for me when running on Firefox or IE. If I back out the Mojarra version to 2.1.6, I get the same issue with IE and FF where the popup doesn't display anything. Not convinced that this is a Mojarra related-regression at this point. Inspecting the HTML in Firebug, I can see that the content for the panel popup is contained in the div, it's just having troubles displaying it. Perhaps it's missing a resource (although there are no errors on the client or the server).

ICE-3190: This works fine for me in both Chrome and Firefox using the latest from the trunk (r29668) which includes the patched version of Mojarra 2.1.9.

ICE-4137: This works fine for me in both Chrome and Firefox using the latest from the trunk (r29668) which includes the patched version of Mojarra 2.1.9.

I cannot run the ajax test of any of the mentioned test applications. The following exception is thrown on the server:

javax.servlet.ServletException: /tooltipAjax.xhtml: Property 'ajaxEventListener' not found on type org.icefaces.tooltip.AjaxTestBean
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)

root cause

javax.el.ELException: /tooltipAjax.xhtml: Property 'ajaxEventListener' not found on type org.icefaces.tooltip.AjaxTestBean
com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:94)
com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
org.icefaces.impl.renderkit.RendererWrapper.encodeChildren(RendererWrapper.java:49)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)

The above failures are also reproducible using http://server.ice:8888/svn/ossrepo/icefaces3/scratchpads/ICE-8156, which is svn rvn #29500 (pre-dates resource loading changes) with Mojarra 2.1.9 (patched). So this would indicate that the patch does not resolve the issues above.

These are the additional ACE failures due to the Mojarra upgrade:

New failures:
Chrome / Firefox: tooltip, slider, resizable, pushButton, progressBar, panel, maskedEntry, notificationPanel, linkButton, draggableDroppable, dialog, dateTimeEntry, dataTable, dataExporter, checkboxButton

(All ajax tests fail manually for the above componenets. The value inside the input text does not always get updated on the page when the ajax listener is called or when resetting the values)

Test apps are located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly

Linking to case outlining steps for dealing with the specific changes that caused the regressions.

To summarize, the reported issues are in one of the following categories:

• not regressions as they behave similarly with Mojarra 2.1.6 and 2.1.8
• cannot be reproduced
• are valid regressions related to the changes made in to jsf.js in http://java.net/jira/browse/JAVASERVERFACES-2381

Regarding:

Internet Explorer:
ICE-1993 - fails in IE - city, state and country not rendered on page after selecting from the autocomplete drop down list.

I only see an issue if I attempt to use the keyboard arrows to select a city from the drop down rather than the mouse. But the problem occurs with 2.1.6 as well as 2.1.8 and the following exception is thrown on the server.

java.lang.NumberFormatException: For input string: "undefined"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:449)
at java.lang.Integer.parseInt(Integer.java:499)
at com.icesoft.faces.component.ext.KeyEvent.getKeyCode(KeyEvent.java:95)
at com.icesoft.faces.component.selectinputtext.SelectInputText.queueEventIfEnterKeyPressed(SelectInputText.java:584)
at com.icesoft.faces.component.selectinputtext.SelectInputText.decode(SelectInputText.java:123)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1181)
at javax.faces.component.UIInput.processDecodes(UIInput.java:662)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1176)
at javax.faces.component.UIForm.processDecodes(UIForm.java:225)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1176)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1176)
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:933)
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)

Regarding:

Internet Explorer:
ICE-3057 There is a rendering issue when clicking on the Tab1 tab pane (IE only), see attached 3057.png.

The rendering looks the same to me in both 2.1.6 and 2.1.8 when running with IE so doesn't appear to be a regression.

Regarding:

ICE-2113 Fails manually: the modal popup panel renders as in attached image in FF and IE (2113.png), and clicking the 'Close' button on the modal popup panel does not un-check the check box, as expected by the test.

I can confirm the rendering issue as noted in the screenshot on both FF and IE. However, the behaviour is present running on Mojarra 2.1.6 for me as well.

The clearing of the checkbox is a regression but is fixed by reverting the changes to jsf.js.

Regarding:

ICE-3190 Fails manually in Firefox (3.6/12): after entering text in the text entries, clicking the 'Clean' button does not clear the text entry and the check box components. Test passes manually in IE and Chrome.

I cannot reproduce this. It works fine for me using either Mojarra 2.1.6 or 2.1.8.

Regarding:

Firefox/Chrome:
ICE-4317 Fails manually in Firefox (3.6/12) and Chrome: after entering text into text entry and selecting check boxes and radio buttons, when the 'Clear All' button is clicked, the text entry, the check boxes and the radio buttons are not cleared. Passes manually in IE only.

Confirmed the problem behaviour and also confirmed that replacing the modified jsf.js file fixes the problem. There was a second change in the code to help with changing the "value" attribute in IE but that seems to have broken the other browsers (Firefox/Chrome/Safari).

Regarding the following:

2) auctionMonitor:
Chrome:
Rendering issue, when clicking to bid on an item a yellow rectangle renders, highlighting the first row in the table. This cannot be removed until clicking outside the bid table, as example to sort items by bids. Screenshot attached, auctionMonitor-render.png.

I see the same behaviour but I get a grey rectangle rather than a yellow (but that might just be OS differences). However, I see the same thing on our public demo so I'd say this is not a regression.

http://auctionmonitor.icesoft.org/auctionMonitor/auctionMonitor.jsf

Firefox:
chat fails; first user that joins chat cannot send a message.

Internet Explorer:
chat fails, a JS error happens when user1 clicks to join chat.

for trunk revision# 29167, re-tested the above issues manually and confirmed that both issues have been fixed.

So looks like at least some of the issues are our own fault. Changes were made to jsf.js as per:

http://java.net/jira/browse/JAVASERVERFACES-2381

We submitted this as part of suggested fix to help with our own DOM diff work but I can't find the specific case. Perhaps this one:

http://jira.icesoft.org/browse/ICE-7803

In any event, the change was to how the attributes of a DOM node where retrieved and compared. Here's the relevant diff:

[deryk] resources > svn diff -r9903:9904 jsf.js
Index: jsf.js
===================================================================
— jsf.js (revision 9903)
+++ jsf.js (revision 9904)
@@ -691,8 +691,8 @@
// First, copy over core attributes
for (iIndex = 0,iLength = coreElementAttributes.length; iIndex < iLength; iIndex++) {
attributeName = coreElementAttributes[iIndex];

• newValue = source[attributeName];
• oldValue = target[attributeName];
  + newValue = source.getAttribute(attributeName);
  + oldValue = target.getAttribute(attributeName);
  if (oldValue != newValue) { target[attributeName] = newValue; }

  @@ -702,8 +702,8 @@
  if (target.nodeName.toLowerCase() === 'input') {
  for (iIndex = 0,iLength = inputElementAttributes.length; iIndex < iLength; iIndex++) {
  attributeName = inputElementAttributes[iIndex];

• newValue = source[attributeName];
• oldValue = target[attributeName];
  + newValue = source.getAttribute(attributeName);
  + oldValue = target.getAttribute(attributeName);
  if (oldValue != newValue) { target[attributeName] = newValue; }

The problem is that some attributes exist that can only be retrieved the "old" way. For example, if I try to get "className":

var theInputText = document.getElementById('j_idt22:in');
<input class=​"A" id=​"j_idt22:​in" lang=​"en" name=​"j_idt22:​in" size=​"15" style title=​"A" type=​"text" value=​"A">​

theInputText['className'];
"A"

theInputText.getAttribute('className');
null

This is because "className" is a hard attribute of the node in the DOM, but "className" is not in the collection of attributes. In that collection, it's called "class".