ICEpush
  1. ICEpush
  2. PUSH-384

Update seen on parent window after closing of child window.

    Details

      Description

      An application is set to be able to open new browser windows/tabs. These new windows have an active push connection as well as the parent window.

      Upon close of a child window, an update is sent to the parent window.

      This JIRA is to better understand this behavior as it might be a requirement for a multiple window ICEpush usage.

        Issue Links

          Activity

          Hide
          Arran Mccullough added a comment -

          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
          Show
          Arran Mccullough added a comment - 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
          Hide
          Mircea Toma added a comment -

          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.

          Show
          Mircea Toma added a comment - 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.
          Hide
          Mircea Toma added a comment - - edited

          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.

          Show
          Mircea Toma added a comment - - edited 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.
          Hide
          Ken Fyten added a comment -

          Re-opened.

          Show
          Ken Fyten added a comment - Re-opened.
          Hide
          Ken Fyten added a comment -

          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.

          Show
          Ken Fyten added a comment - 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.
          Hide
          Mircea Toma added a comment -

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

          Show
          Mircea Toma added a comment - The issues this JIRA case depends on are fixed. Marking this as resolved.

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Arran Mccullough
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: