Attached test case that shows this behavior.

Steps:

• Load welcomeICEfaces.jsf
• Open a browser console.
• Click the link to open a new window.
• Close the new browser window. Something similar to the following will show in the console log:
  [icepush.dc99e.async-connection] [Wed, 24 Feb 2016 19:04:29 GMT] blocking connection lease expired...candidate for its creation icepush.uncompressed.js.jsf:699:84
  [icepush.dc99e.async-connection] [Wed, 24 Feb 2016 19:04:30 GMT] initialize connection within window dc99e icepush.uncompressed.js.jsf:699:84
  [icepush.dc99e.async-connection] [Wed, 24 Feb 2016 19:04:30 GMT] closing previous connection... icepush.uncompressed.js.jsf:692:85
  [icepush.dc99e.async-connection] [Wed, 24 Feb 2016 19:04:30 GMT] connect... icepush.uncompressed.js.jsf:692:85
  [icefaces] [Wed, 24 Feb 2016 19:04:30 GMT] picking updates for view vf3epk2 bridge.uncompressed.js.jsf:1352:85
  [icepush.dc99e.pushid-expiry] [Wed, 24 Feb 2016 19:04:30 GMT] resume monitoring for unused pushIDs icepush.uncompressed.js.jsf:699:84
  [icefaces] [Wed, 24 Feb 2016 19:04:30 GMT] applied updates >>
  update["javax.faces.ViewState"]: 5778793053549721472:7383055232890824844....
  eval: var iceFormIdList=['iceForm', 'vf3epk2-r.... bridge.uncompressed.js.jsf:1352:85

The observed behaviour is the one expected. When the popup window is opened the blocking connection ownership moves from the parent to the popup window. When the popup is closed the ownership of the blocking connection moves back to the parent window. Every time the blocking connection moves to a different window there will be a request for updates issued to ensure that pending notifications (that might have been issued while blocking connection changes window) are acquired.

Here are the answers to your questions:

1) Because Opera doesn't invoke window.onuload callbacks on window close, so to avoid relying on it for passing blocking connection ownership the connection marker (used to be a cookie, now a localStorage entry) is removed and thus the functioning windows (who monitor the marker) will fight for owning the blocking connection. See http://jira.icesoft.org/browse/ICE-1872 . Wow, I cant believe it's been so long ago.

2) I guess there might be use cases where it would be reasonable to have the request for updates disabled when the blocking connection moves to another window. For example applications where missing updates is not critical or the asynchronous updates are not triggered very often.

Re-opened.

After further review we believe that it should now be feasible to modify the behaviour of icepush to greatly reduce the occurrences of push connections and updates being requested when working with multiple tabs and/or browser windows via the following linked JIRAs:

PUSH-387 - Avoid blocking connection switchover whenever a new window is opened.

ICE-10992 - Introduce context parameter for disabling request for updates on page load.

The issues this JIRA case depends on are fixed. Marking this as resolved.