To reproduce this issue I use the following steps:

1. Run the auction-monitor demo on another machine
2. Load auction-monitor into your browser (on a machine other than the tomcat one)
3. See the clocks tick.
4. Put the browser machine to sleep
5. Wait longer than the session expiry internal on the app.
6. Wake the browser machine
7. See no clocks ticking.
8. Interact with the application.
9. See the "Session Expired" dialog.
10. Click "reload" on the dialog.
11. App reloads, see no clocks ticking.
12. Interact with the app., see the app. functioning.
13. See no clocks ticking.
14. Open another tab for the app., see clocks ticking in new tab now.

I managed to reproduce the issue when following the steps provided above. The problem doesn't show up consistently though, approximately only 1 out of 5 retries will manage to exhibit the problem.
It seems that the problem is not on the client side nor ICEpush, not even ICEfaces but in JSF or the servlet container. In the occurrences when the blocking connection is not restarted the inline JS code the registers the pushIDs with the ICEpush bridge is not present (ice.setupPush(....) call). This code is rendered by BridgeSetup which decide to render the initialization code based on the value returned by LazyPushPanger.enablePush method. The method will return true when lazy push is disabled or when the rendered view requires ICEpush support, this is done usually by calling PushRenderer.addCurrentSession or PushRenderer.addCurrentView methods.
In auctionMonitor PushRenderer.addCurrentSession is called indirectly (through the old SessionRenderer) from the UserBean constructor, a session scoped bean. The problem occurs here, when a new session is created a new bean is instantiated and PushRenderer.addCurrentSession is called. When the blocking connection does not start there is no UserBean instantiated thus PushRenderer.addCurrentSession is not called.
Even if a new @PostConstruct annotated method is introduced to invoke PushRenderer.addCurrentSession on session activation does not seem to help. Making the bean Externalizable to verify if the bean is created by deserialization shows that that is not the case.

Modified WindowScopeManager to try to discard the window scope when dispose window request is received after a browser window unload, ensuring that no scope map that should have been expired is still used.
This issue occurred because after the browser machine is put to sleep no other requests are coming in, to allow the server side code to check if the window scopes belonging to a certain session should be discarded or not.