ICEfaces4 trunk r45829: verified PUSH-343 in IE11, Chrome43, Firefox34.

As noted in the comment above, there are actually a couple of issues here:

1. When a second IE window is opened using "New Tab" or "New Window" and does not create a new session, an exception tends to occur relatively quickly on the server.
2. When a second IE window is opened using "New Session", ownership of the blocking connection bounces back and forth between the windows causing problems with updates and performance.

This case was originally opened for issue #2. Since issue #1 is a completely separate issue, I've opened a new JIRA for it and copied the relevant information over: ICE-10796.

Testing localStorage's behaviour in IE11 shows once again that the storage entries modified in the window opened with "New Session" option will only occasionally see the changes made in the first window (or the other way around). The expected behaviour for IE11 is explained here, paragraph #3: http://blogs.msdn.com/b/ieinternals/archive/2009/09/16/bugs-in-ie8-support-for-html5-postmessage-sessionstorage-and-localstorage.aspx . Even with this buggy behaviour our code should have worked fine. All I can assume is that they tried to fix something since 2009 when the page was published but not fully fix localStorage's behaviour. This partial implementation of localStorage when "New Session" option is used cripples our use of localStorage.

Disable usage of localStorage feature when IE is detected. Using the cookie based implementation for inter-window communication in IE ensures the expected behaviour when "New Session" option is used.

Tested with auction applications from ICEfaces 4 trunk, ee- 3.3.0 maintenance branch r45992. No issues found.