For the language selection, this is the relevant snippet being passed to the server:

iceform%3ASlctLang=true&iceform%3ASlctLang=false&iceform%3ASlctLang=false&iceform%3ASlctLang=false&iceform%3ASlctLang=true

In contrast, here is what we send with ICEfaces 1.8 trunk:

iceform%3Aicepnltabset%3A0%3ASlctLang=bean.selection.language.lang5.value&iceform%3Aicepnltabset%3A0%3ASlctLang=bean.selection.language.lang2.value&iceform%3Aicepnltabset%3A0%3ASlctLang=bean.selection.language.lang1.value

The component hierarchy is slightly different, but the important point to notice is that the values are not true or false, they are of the form "bean.selection.language.lang5.value".

It is possible that the JSF standard JavaScript is encoding the values incorrectly.

I will test with an updated JSF implementation.

Using jsf-api.jar and jsf-impl.jar from glassfish-v3-web-preview-b52.zip shows no change. Further investigation is required.

This appears to be a bug in the JSF 2.0 JavaScript bridge implementation.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1184

Issue is reported and candidate fix is suggested.

Border panel with checkboxes in compat/component-showcase still behaves strangely, however.

Change has been checked in to JSF 2.0:

------------------------------------------------------------------------
r7499 | driscoll | 2009-07-07 10:43:15 -0600 (Tue, 07 Jul 2009) | 7 lines
Changed paths:
M /trunk/jsf-api/resources/jsf.js
M /trunk/jsf-ri/src/com/sun/faces/renderkit/RenderKitUtils.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/AjaxBehaviorRenderer.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/CheckboxRenderer.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/MenuRenderer.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/RadioRenderer.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/SecretRenderer.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/SelectManyCheckboxListRenderer.java
M /trunk/jsf-ri/src/com/sun/faces/renderkit/html_basic/TextRenderer.java
M /trunk/jsf-ri/systest/src/com/sun/faces/ajax/AjaxTagWrappingTestCase.java
M /trunk/jsf-ri/systest/src/com/sun/faces/systest/model/ajax/AjaxTagValuesBean.java
M /trunk/jsf-ri/systest/web/ajax/ajaxTagWrapping.xhtml

Fix for Bug 1184

Previously, selectManyCheckbox did not work with ajax calls. The individual cells were being passed back into visitTree, and when the visit occured, nothi
ng was found, since they're not valid to visit. The fix involves passing a parameter to AjaxBehaviorRenderer, which signals adding the client id to the re
ndered ajax call, instead of using the default, which is the individual cell.

Added tests to ensure no regressions.

r=rogerk

City selection throws validation error:

sourceId=iceform:citiesListBox[severity=(ERROR 2), summary=(iceform:citiesListBox: Validation Error: Value is not valid), detail=(iceform:citiesListBox: Validation Error: Value is not valid)]

This was fixed by changing SelectionTagsBean to View scope. The Validation Error occurred because the country and city were not necessarily available in the order expected in a given request, for instance, the country may be null when the city list is being rendered.

With the use of View scope, the value selected by the user in the previous request is guaranteed to be available.

Mircea, please comment on why focus appears to be lost with the selectMany components. Is it a difference in behavior between the JSF 2.0 JavaScript DOM manipulation and ICEfaces DOM manipulation?

The strange behavior of borderPanel is due to the fact that the backing bean is in request scope and uses ValueChangeListener to update. In request scope, the bean has default values for each request, so only sees the correct value for the one checkbox that is selected. The solution is to either use values directly or to use beans in view scope.

ice:loadBundle was not working correctly during the decode phase. Rather than attempt to repair ice:loadBundle, it probably makes more sense to recommend that people switch to f:loadBundle.

> Mircea, please comment on why focus appears to be lost with the selectMany components. Is it a difference in behavior
> between the JSF 2.0 JavaScript DOM manipulation and ICEfaces DOM manipulation?

There are two things that are different:
a) There is no update for the 'select' element that triggered the submit. We have BridgeFacesContext.applyBrowserChanges() method that applies the changes from the browser to the old DOM thus canceling useless updates.
b) selectOne and selectMany components are sending an additional focus command that helps maintaining focus on the submit triggering element.

Apply input values to old DOM to avoid generating pointless updates. As side effect the focus is preserved on the submit triggering element.

Excellent; this fix was also needed to clear the input field in the chat portion of the auction demo.

Focus is working well in component-showcase now, however, the chat field mentioned above loses focus (I will add this investigation to an auction-specific bug).