The checkin where this started to fail was 17584:

[deryk] icefaces > svn diff -r17583:17584Index: core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java
===================================================================
— core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java (revision 17583)
+++ core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java (revision 17584)
@@ -220,7 +220,11 @@
//facesContext.renderResponse() skips phase listeners
//in JSF 1.2, so do a full execute with no stale input
//instead

• facesContext.getExternalContext().getRequestParameterMap().clear();
  + Map requestParameterMap =
  + facesContext.getExternalContext().getRequestParameterMap();
  + requestParameterMap.clear();
  + //Seam appears to need ViewState set during push
  + requestParameterMap.put("javax.faces.ViewState", "ajaxpush");
  } else { facesContext.renderResponse(); }

This change was added to fix ICE-3532. The PersistentFacesState.execute method has undergone other changes since the, included some Seam specific modifications. The current code looks like this:

Map requestParameterMap =
facesContext.getExternalContext().getRequestParameterMap();
requestParameterMap.clear();
if (SeamUtilities.isSeamEnvironment())

//Seam appears to need ViewState set during push
requestParameterMap.put("javax.faces.ViewState", "ajaxpush");

The suggested fix is to move:

requestParameterMap.put("javax.faces.ViewState", "ajaxpush");

into the code block that checks for the Seam environment as the action is specific to Seam anyway.

This appears to be a combination of the the fix noted above for Seam and the way that the GMap component looks for an empty request map to update the location. Rather than risk the stability of the imminent release, we decided to try and fix the Location demo. This involves binding the locateAddress attribute of the component to the Map bean in a way that an update triggers a change of location and then sets the attribute to false.