ICEfaces
  1. ICEfaces
  2. ICE-3691

Initial page rendered on page reload after forward navigation executed

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.2, 1.8DR#1
    • Fix Version/s: 1.7.2 SP1, 1.8DR#2, 1.8
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      server

      Description

      When page is reloaded after navigating using forward navigation rules, instead of reloading the last view ID determined by the navigation rules the initial view ID is rendered.

        Issue Links

          Activity

          Mircea Toma created issue -
          Mircea Toma made changes -
          Field Original Value New Value
          Assignee Mircea Toma [ mircea.toma ]
          Hide
          Mircea Toma added a comment -

          Greg's findings:
          "Looking at the application mentioned in the post ( A snappy client side ICEfaces compatible calendar from Rob Mayhew) I see what is happening.

          The application does navigation from the main page to the calendar page without using redirection. This means that the URL in the title bar always remains:
          http://localhost:8080/jspx&rvn=1

          even though we have navigated. Hitting F5 in a purely JSF application causes the browser to submit the last post aubmitted and this causes re-navigation to the same page as before the reload, otherwise, it would wind up reloading the first page as well. The browser in an ICEfaces application doesn't do this, but merely issues a reload command which causes us to depend on the view preservation behaviour. I guess this gets into the unwanted re-posting of credit card details if one reloads the page in a JSF app from the order page.

          It's an interesting observation that the execution in JSF is considered to be a postback."

          Show
          Mircea Toma added a comment - Greg's findings: "Looking at the application mentioned in the post ( A snappy client side ICEfaces compatible calendar from Rob Mayhew) I see what is happening. The application does navigation from the main page to the calendar page without using redirection. This means that the URL in the title bar always remains: http://localhost:8080/jspx&rvn=1 even though we have navigated. Hitting F5 in a purely JSF application causes the browser to submit the last post aubmitted and this causes re-navigation to the same page as before the reload, otherwise, it would wind up reloading the first page as well. The browser in an ICEfaces application doesn't do this, but merely issues a reload command which causes us to depend on the view preservation behaviour. I guess this gets into the unwanted re-posting of credit card details if one reloads the page in a JSF app from the order page. It's an interesting observation that the execution in JSF is considered to be a postback."
          Deryk Sinotte made changes -
          Fix Version/s 1.8DR#2 [ 10142 ]
          Assignee Priority P1
          Hide
          Tolnai Andrei added a comment -

          This bug is a duplicate of bug http://jira.icefaces.org/browse/ICE-3632

          Show
          Tolnai Andrei added a comment - This bug is a duplicate of bug http://jira.icefaces.org/browse/ICE-3632
          Mircea Toma made changes -
          Link This issue duplicates ICE-3632 [ ICE-3632 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #17851 Tue Oct 28 15:33:40 MDT 2008 mircea.toma ICE-3691 Reuse FacesContext on reload to preserve the ViewRoot in case forward navigation rules were executed.
          Files Changed
          Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/core/SingleViewServer.java
          Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/BridgeFacesContext.java
          Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/core/MultiViewServer.java
          Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/View.java
          Hide
          Mircea Toma added a comment -

          Reuse FacesContext on reload to preserve the ViewRoot in case forward navigation rules were executed.

          Show
          Mircea Toma added a comment - Reuse FacesContext on reload to preserve the ViewRoot in case forward navigation rules were executed.
          Mircea Toma made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #17876 Fri Nov 07 03:45:10 MST 2008 mircea.toma ICE-3691 Reuse FacesContext on reload except in a Seam environment.
          Files Changed
          Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/View.java
          Hide
          Mircea Toma added a comment -

          Reuse FacesContext on reload except in a Seam environment.

          Show
          Mircea Toma added a comment - Reuse FacesContext on reload except in a Seam environment.
          Mircea Toma made changes -
          Link This issue is duplicated by ICE-3713 [ ICE-3713 ]
          Ken Fyten made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Ken Fyten made changes -
          Fix Version/s 1.7.2 SP1 [ 10144 ]
          Hide
          Mircea Toma added a comment -

          Yes, it can be backported but I have to pull in a few other changes.

          Show
          Mircea Toma added a comment - Yes, it can be backported but I have to pull in a few other changes.
          Mircea Toma made changes -
          Status Reopened [ 4 ] In Progress [ 3 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #17907 Mon Nov 17 15:11:53 MST 2008 mircea.toma ICE-3691 Backport fixes from trunk together with the still standing fixes for ICE-3590.
          Files Changed
          Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/core/src/com/icesoft/faces/webapp/http/core/MultiViewServer.java
          Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/bridge/src/application.js
          Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/core/src/com/icesoft/faces/webapp/http/core/SingleViewServer.java
          Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/core/src/com/icesoft/faces/context/BridgeFacesContext.java
          Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/core/src/com/icesoft/faces/context/BridgeExternalContext.java
          Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/core/src/com/icesoft/faces/context/View.java
          Hide
          Mircea Toma added a comment -

          Backport fixes from trunk together with the still standing fixes for ICE-3590.

          Show
          Mircea Toma added a comment - Backport fixes from trunk together with the still standing fixes for ICE-3590 .
          Mircea Toma made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Ken Fyten added a comment -

          Regression testing shows this is still not working for the case where just-ice.jar is configured on Tomcat 5 (instead of icefaces.jar).

          Show
          Ken Fyten added a comment - Regression testing shows this is still not working for the case where just-ice.jar is configured on Tomcat 5 (instead of icefaces.jar).
          Ken Fyten made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          Ken Fyten added a comment -

          Comment from Mircea:

          I don't think this test was ever written to run with just-ice.jar and JSF1.1. h:commandLink uses a Javacript function that
          h:form is responsible to render. So, as a consequence h:commandLink (in JSF1.1) doesn't work with ice:form ... it throws a Javascript error and the browser fails to submit the form. In JSF 1.2 this dependency h:commandLink->h:form does not exist anymore, that's why the test works fine in Tomcat6.0.

          Show
          Ken Fyten added a comment - Comment from Mircea: I don't think this test was ever written to run with just-ice.jar and JSF1.1. h:commandLink uses a Javacript function that h:form is responsible to render. So, as a consequence h:commandLink (in JSF1.1) doesn't work with ice:form ... it throws a Javascript error and the browser fails to submit the form. In JSF 1.2 this dependency h:commandLink->h:form does not exist anymore, that's why the test works fine in Tomcat6.0.
          Ken Fyten made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Assignee Priority P1
          Resolution Fixed [ 1 ]
          Mircea Toma made changes -
          Link This issue blocks ICE-3886 [ ICE-3886 ]
          Ken Fyten made changes -
          Fix Version/s 1.8 [ 10161 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Assignee Mircea Toma [ mircea.toma ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: