Forms don't submit when mixed w/ Javascript

Question

Greetings,
I have a problem with a JSF application
I have a JSF form with a number of text fields (h:inputText) and text areas. None are set to be required and all use the default validators, converters, etc. Each text element is bound to a String property of a backing bean. All works fine under 'normal' conditions. I submit the form, the values are all set on the backing bean, all is well.
Next to one (or more) of the textfields, however, there is a "Select..." button (h:commandButton) with a javascript call on the 'onmousedown' event that launches a new window (this is a slightly modified version of the example found at http://forum.exadel.com/viewtopic.php?t=559 by Sergey Smirnov). The selected value in the popup window is used to set the value on the original form text field. Then the original form can be submitted.
When I use one of these buttons to launch a new window (pop-up) with a JSF-based select list in it, I get unusual behavior. The syptoms I see are:
1. If the popup list itself submits and refreshes (such as in the case of an indexed list, and the user selects a new index) the value is set properly on the 'opener' form, but when I submit the 'opener' form, the value reverts back to its previous (before the pop-up was launched) value.
2. Especially with more than 1 pop-up on a form, I often see the case where I submit the form, and it simply refreshes itself, and all values are cleared from the form elements. My ActionListeners and other action events are never invoked. No messages are sent back to the page via the faces context. I get no notification of what went wrong.
3. The behavior I get is hit or miss, sometimes it works well, other times it never works.
4. Strangely, it seems that if I click more slowly, things tend to work better more often. Rapid clicking seems to make the failure much more likely.
The Button looks like this:
<h:inputText id="itemValue" value="#{item.value}"/>
<h:inputHidden id="itemId" value="#{item.id}"/>
<h:inputHidden id="itemTypeId" value="#{item.typeId}"/>
<h:commandButton id="find" action="showList" value="Select..."
onmousedown="showList(this,'itemValue', 'itemId', 'itemTypeId')"
onclick="return false"/>
The javascript showList() method registers the html components itemValue, itemId, and itemTypeId for callbacks, and launches a window using a pre-defined href value. Inside this window is a JSF page that lists all of the available items as h:commandLink objects. When one of the links is selected, the pop-up window calls a javascript function on the 'opener' window to set the itemValue, itemId, and itemTypeId values according to the selected item.
function showList(action, nameFieldComponent, idFieldComponent, itemTypeIdComponent) {
//url to the chooser.jsp file opened in the new window
var href='<h:outputText value="#{bundle.chooser_javascript_href}" />';
var features='<h:outputText value="#{bundle.chooser_javascript_window_properties}" />';
<...snipped out details for brevity - resolves the form and component ids for callbacks >
//open the new window
winId=window.open(href,'chooserWindow',features);
A javascript function in the chooser.jsp calls back and update() method, which sets the values on the name, id, and typeId form elements. All this works fine.
It's AFTER all this, when I submit the form on the original page, that I get the errors.
I suspect that somehow with more than 1 window open, I've managed to confuse the Faces navigation and view management - does anybody have any insights to help me solve the problem?
Also, how can I better debug what is happening on the server when my action listener is never getting invoked?

Answer 1

This is just a shot in the dark, but have you tried switching to client-side state saving?
When you use server-side state saving, the JSF RI only keeps the state for one view around. If your pop-ups are created by JSF views, popping up one of them detroys the state for the main view on the server, which could cause the effects you describe. Switching to client-side state saving should solve this, because then the view state is held as hidden fields in each form instead, and hence, can't be destroyed.