Need re-evaluate this issue as the previous fixes caused regressions as reported in ICE-10705

To fix this issue we had to understand how IE11's localStorage behaves when a new window is created with "New Session" option. It turns out that the localStorage map of the new window has the entries copied from the localStorage map of the first window. Change in the any of the values will remain local to that window. Another IE11 quirk is that when the new window is created the blocking connection in the first window is aborted without any reason by the browser. Also while the blocking connections run in each of the windows, occasionally one of the blocking connection is aborted.

The changes took this quirks into account. Now the bridge does not use localStorage for keeping the browser ID value, it will use only the cookie instead. This avoid data duplication and matching lifecycle of the value relative to the browser session. Also the blocking connection's lease is verified if expired regardless of connection status (owned, running ....) thus ensuring that the connection is re-started when connection is aborted by the browser (as opposed by the bridge).

Q: _"The console logs also show connection updates from other sessions. Is this expected?"
A: The IDs shown in the logs represent individual windows not sessions. Because of the quirks explained in my previous comment the windows will loose from time to time the blocking connection because of the activity in the other windows, but they are recovering the connection right away once detected.

Q: "Are there any further testing steps that should be taken besides examining logs?"
A: Well, we would have to devise a test case where the asynchronous updates are applied to session scoped beans. Then verify if the updates from one session are not sent to both of the browser windows (each connected to a different session).

Re-opening because it causes a regression, PUSH-343 can be reproduced again (easier to reproduce in Chrome):
Push updates stop in all windows when opening showcase > icecore:push demo in multiple browser windows:

• a 3rd separate window in Chrome43
• a 3rd or 4th window in Firefox34 or IE11 (inconsistent results).
  The notifications restart when only one window is left open.

Resolved by the changes committed for PUSH-365.

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.