ICEfaces
  1. ICEfaces
  2. ICE-10753

CLONE - Push connection not running on multiple browser windows/sessions (IE11)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1, EE-3.3.0.GA_P04
    • Fix Version/s: 4.1, EE-3.3.0.GA_P04
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      IE11

      Description

      With IE11 it has the option to create a New Session for a new browser window. Using the EE 3.3.0 P02 release, only the last active window has an ICEpush connection.

      Testing with EE 3.3.0 P01 this is not an issue, each window has it's own push connection.

      1. 1.PNG
        49 kB
      2. IE11-errors.png
        211 kB

        Activity

        Hide
        Arran Mccullough added a comment -

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

        Show
        Arran Mccullough added a comment - Need re-evaluate this issue as the previous fixes caused regressions as reported in ICE-10705
        Hide
        Mircea Toma added a comment -

        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).

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

        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).

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

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

        Resolved by the changes committed for PUSH-365.

        Show
        Mircea Toma added a comment - Resolved by the changes committed for PUSH-365 .
        Hide
        Carmen Cristurean added a comment -

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

        Show
        Carmen Cristurean added a comment - ICEfaces4 trunk r45829: verified PUSH-343 in IE11, Chrome43, Firefox34.
        Hide
        Deryk Sinotte added a comment -

        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.

        Show
        Deryk Sinotte added a comment - As noted in the comment above, there are actually a couple of issues here: 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. 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 .
        Hide
        Mircea Toma added a comment - - edited

        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.

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

        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.

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

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

        Show
        Liana Munroe added a comment - Tested with auction applications from ICEfaces 4 trunk, ee- 3.3.0 maintenance branch r45992. No issues found.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: