Attached test case that shows this issue. Note: the icefaces.jar/icefaces-ace.jar files need to be added back into the war file for it to run.

Steps:

• Load welcomeICEfaces.jsf
• The windowScopeExpiration is set to 20 seconds as well as there is logging to show the creation, getter, and disposal of the Window Scope bean and it's current hash code.
• Wait 20 seconds and do a full browser refresh. A new bean instance is created.
• Do another refresh, the getter will now register two bean has codes.
• Waiting another 20 seconds, will have the older bean instance disposed.

adding example for support case 13228.....use <serveraddress:ip>/windowsScope/13228a.jsf after building this test app (with maven or in eclipse).
Note that the windowsScoped bean gets destroyed and reconstructed (logging in the beans to show this on server log), losing the page parameters (tabsetIndex) very frequently on weblogic ...can see instance with my name on ec2....not quite so often on tomcat7. When I add
<context-param>
<param-name>org.icefaces.windowScopeExpiration</param-name>
<param-value>10000</param-value>
</context-param>
Also, without the push jar, the tabSetIndex (page Parameter) is never lost.
then it is very hard to make it happen that the tabset index is lost.

I cannot reproduce this issue. Once icefaces.jar is added to the deployed test case then the window scoped beans are behaving as expected. I tested with icefaces.jar built off 3.3.0-GA-maintenance and 3.3.0.GA_P02, both worked just fine.

I'm pretty sure the test didn't work because of the missing icefaces.jar file, the window scope feature will not work without it.
Also, the windowScopeExpiration parameter should have a value of 500 to 3000 milliseconds, depending on how long it takes to the most complex page in the application to reload (if the elapsed time between a page unload and the next page load is higher than the windowScopeExpiration value then the scope is disposed and new window scope is created if needed).

It turns out that the fixes for PUSH-347 fixed this issue as well. As already described in PUSH-347 the resource requests used to trigger new window scope creation because they do not contain ice.window parameter.

The relevant commits are #43978 and #44012.

Q: "FF and Chrome - everytime the page was refreshed the getInputOne() method was logged twice."
A: The second getInputOne() method invocation is triggered by a request for updates that is always issued when the blocking connection is established to make sure any update that might have been generated in between connection re-establishment wasn't missed. So yes, it's normal.

Q: "IE 11 - the page appears to refresh constantly so the getInputOne() method is logged approximately every second."
A: I tried my local version of IE11 and also the instance on 10.18.39.107 but I could not reproduce the problem.

Verified Case13258Example, ICEfaces 4 trunk, ee-3.3.0 maintenance branch r44012. Verified windowsScopes test case ee-3.3.0 maintenance branch r44012. Could not re-create the IE 11 logging issue on my local machine or on 10.18.39.107 IE 11 test machine.