ICEfaces
  1. ICEfaces
  2. ICE-7759

WindowScope Bean stops reloading on quick browser refresh

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-2.0.0.GA, 3.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      IE8/9, Chrome

      Description

      Quickly refreshing the browser (Chome and IE) in quick succession the window scope beans stops constructing itself upon browser refresh. The view scoped bean still refreshes. If the page is left to load completely between refreshes then the window scope bean works correctly.

        Activity

        Hide
        Arran Mccullough added a comment -

        Test case that reproduces the issue. This is the code from the Window Scope tutorial. Quickly refreshing the browser causes the window scope bean to stop constructing itself on refresh. Using the F5 button to refresh can show the issue quickly.

        Show
        Arran Mccullough added a comment - Test case that reproduces the issue. This is the code from the Window Scope tutorial. Quickly refreshing the browser causes the window scope bean to stop constructing itself on refresh. Using the F5 button to refresh can show the issue quickly.
        Hide
        Dan Ertman added a comment -

        I'm the original submitter (to support) of this issue. I think things have gotten confused, so I wanted to clarify what we're seeing and what we expect to see.

        1. We expect that "window scope" means "for the life of the browser window" - that a bean declared in window scope should be constructed the first time it is accessed by a particular browser window, and that that same bean instance should be used for multiple requests / responses (all, really) in this browser window. Hopefully that understanding is correct.

        2. Therefore, in the tutorial display, we should NOT see the memory ID of the window-scoped-bean change ever, really, unless we open a new browser window and navigate to the same page. Each window should be allocated one window-scoped bean and that bean should remain constant. This is longer than view-scope but different than session-scope, which I think is the idea.

        3. What we do see is if we use F5 / browser controls to refresh the page, the memory ID of the window-scoped-bean changes. It is reconstructed. We see similar behavior in production code - the state of window-scoped beans is lost and they are reconstructed. This disagrees with our understanding of window-scope, hence we think it is a bug.

        4. Equally troublesome, in some cases that I haven't been able to narrow down, it's possible for two different browser windows to end up with the references to the same window-scoped bean - i.e. they behave identically to session-scoped beans.

        5. What Arran describes - refreshing rapidly doesn't reconstruct the beans - is interesting, since the behavior we expect is that the bean is never reconstructed.

        Show
        Dan Ertman added a comment - I'm the original submitter (to support) of this issue. I think things have gotten confused, so I wanted to clarify what we're seeing and what we expect to see. 1. We expect that "window scope" means "for the life of the browser window" - that a bean declared in window scope should be constructed the first time it is accessed by a particular browser window, and that that same bean instance should be used for multiple requests / responses (all, really) in this browser window. Hopefully that understanding is correct. 2. Therefore, in the tutorial display, we should NOT see the memory ID of the window-scoped-bean change ever, really, unless we open a new browser window and navigate to the same page. Each window should be allocated one window-scoped bean and that bean should remain constant. This is longer than view-scope but different than session-scope, which I think is the idea. 3. What we do see is if we use F5 / browser controls to refresh the page, the memory ID of the window-scoped-bean changes. It is reconstructed. We see similar behavior in production code - the state of window-scoped beans is lost and they are reconstructed. This disagrees with our understanding of window-scope, hence we think it is a bug. 4. Equally troublesome, in some cases that I haven't been able to narrow down, it's possible for two different browser windows to end up with the references to the same window-scoped bean - i.e. they behave identically to session-scoped beans. 5. What Arran describes - refreshing rapidly doesn't reconstruct the beans - is interesting, since the behavior we expect is that the bean is never reconstructed.
        Hide
        Mircea Toma added a comment -

        Here are the replies to each numbered paragraph:

        1. Yes, that is correct.
        2. Exactly, the window scoped bean instances should be created only when new windows/tabs are opened.
        3. This is indeed the issue we need to investigate, what is different when F5 is pressed versus normal page reload.
        4. Yes, window scope beans should not be reconstructed on page reload.

        Show
        Mircea Toma added a comment - Here are the replies to each numbered paragraph: 1. Yes, that is correct. 2. Exactly, the window scoped bean instances should be created only when new windows/tabs are opened. 3. This is indeed the issue we need to investigate, what is different when F5 is pressed versus normal page reload. 4. Yes, window scope beans should not be reconstructed on page reload.
        Hide
        Mircea Toma added a comment -

        It turns out that there were a couple of (subtle) issues with the window scope.

        First the detection of beans in the window scope map needed to be fixed, the test for beans with names outside of "org.icefaces.impl" package was made on the keys of the map instead of the values.

        Secondly there was the detection of window scoped beans, during page load the detection would fail because when the test was run the beans where not added yet into the scope map. The fix runs the test now during render phase when it is certain that the beans were added into the map.

        Show
        Mircea Toma added a comment - It turns out that there were a couple of (subtle) issues with the window scope. First the detection of beans in the window scope map needed to be fixed, the test for beans with names outside of "org.icefaces.impl" package was made on the keys of the map instead of the values. Secondly there was the detection of window scoped beans, during page load the detection would fail because when the test was run the beans where not added yet into the scope map. The fix runs the test now during render phase when it is certain that the beans were added into the map.
        Hide
        Dan Ertman added a comment -

        Possible to build a patch for EE 2.0? We're not on 3.0 and not planning to migrate in the near term.

        Show
        Dan Ertman added a comment - Possible to build a patch for EE 2.0? We're not on 3.0 and not planning to migrate in the near term.
        Hide
        Mircea Toma added a comment -

        EE 2.0 branch was patched.

        Show
        Mircea Toma added a comment - EE 2.0 branch was patched.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: