Uploaded image for project: 'PUBLIC - Liferay Faces'
  1. PUBLIC - Liferay Faces
  2. FACES-2971

State not restored in JSF 2.3 due to ViewState and ClientWindowState encoded with extra colon

    Details

      Description

      The JSF 2.3 ViewState and ClientWindowState are encoded with an extra colon. However, Liferay Faces still encodes the state without the extra colon. Because of this, the state cannot be restored in some cases.

      Steps to reproduce:

      1. Deploy the jsf-applicant-portlet.
      2. Run the jsf-applicant-portlet tests:

      (cd liferay-faces-bridge-impl/test/integration/ && mvn test -P integration,pluto,chrome -Dintegration.port=8180 -Dtest=*JSFApp*)

      If the bug still exists, the test will fail with the following failures:

      Tests run: 10, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 50.801 sec <<< FAILURE!
      
      Results :
      
      Tests in error:
        runApplicantPortletTest_F_AutoPopulateCityState(com.liferay.faces.bridge.test.integration.demo.applicant.JSFApplicantPortletTester): Timed out after 10 seconds waiting for element ([[ChromeDriver: chrome on MAC (0081c7bed1e091dc30a39215f132d649)] -> xpath: //input[contains(@id,':postalCode')]])to become stale(..)
        runApplicantPortletTest_G_Comments(com.liferay.faces.bridge.test.integration.demo.applicant.JSFApplicantPortletTester): Timed out after 10 secondswaiting for element ([[ChromeDriver: chrome on MAC (0081c7bed1e091dc30a39215f132d649)] -> xpath: //a[contains(text(), 'Show Comments') or contains(text(), 'Hide Comments')]]) to become stale(..)
        runApplicantPortletTest_H_DateValidation(com.liferay.faces.bridge.test.integration.demo.applicant.JSFApplicantPortletTester): Timed out after 10 seconds waiting for element ([[ChromeDriver: chrome on MAC (0081c7bed1e091dc30a39215f132d649)] -> xpath: //input[contains(@id,':dateOfBirth')]]) to become stale(..)
        runApplicantPortletTest_I_FileUpload(com.liferay.faces.bridge.test.integration.demo.applicant.JSFApplicantPortletTester): Timed out after 10 seconds waiting for visibility of element located by By.xpath: //tr[@class='portlet-section-body results-row']/td[2](..)
        runApplicantPortletTest_J_Submit(com.liferay.faces.bridge.test.integration.demo.applicant.JSFApplicantPortletTester): no such element: Unable to locate element: {"method":"xpath","selector":"//textarea[contains(@id,':comments')]"}(..)
      
      Tests run: 10, Failures: 0, Errors: 5, Skipped: 0
      

      If the bug is fixed, the test will only fail the file upload test (or the test will have no failures).

        Activity

        Hide
        kyle.stiemann Kyle Stiemann added a comment -

        Work is in progress at these branches:
        https://github.com/stiemannkj1/liferay-faces-bridge-impl/tree/fix-state-for-JSF-2.3-FACES-2971
        https://github.com/stiemannkj1/liferay-faces-bridge-impl/tree/fix-state-for-JSF-2.3-FACES-2971-4.x

        However, the solution there may be inadequate. Neil has informed me that JSF 2.3 may fix the issue which requires our response writer workaround. So we should test without the ResponseWriterBridgeImpl code in JSF 2.3 to see if things are working. The workaround in ResponseWriterBridgeImpl was initially created in order to fix an issue where Mojarra does not write the javax.faces.ViewState input when rerendering a form in a partial response. Before making further changes, Mojarra's behavior in a webapp should be investigated to determine what causes this issue in portlets.

        Note that the changes in JSF 2.3 also break this showcase code. We need to consider a portlet filter which fixes this in order to avoid breaking backwards compatibility.

        Finally, when testing this in JSF 2.3, Mojarra must be patched as described by Neil in JAVASERVERFACES_SPEC_PUBLIC-790.

        FACES-1798 and FACES-1797 are also related to this issue.

        Show
        kyle.stiemann Kyle Stiemann added a comment - Work is in progress at these branches: https://github.com/stiemannkj1/liferay-faces-bridge-impl/tree/fix-state-for-JSF-2.3-FACES-2971 https://github.com/stiemannkj1/liferay-faces-bridge-impl/tree/fix-state-for-JSF-2.3-FACES-2971-4.x However, the solution there may be inadequate. Neil has informed me that JSF 2.3 may fix the issue which requires our response writer workaround. So we should test without the ResponseWriterBridgeImpl code in JSF 2.3 to see if things are working. The workaround in ResponseWriterBridgeImpl was initially created in order to fix an issue where Mojarra does not write the javax.faces.ViewState input when rerendering a form in a partial response. Before making further changes, Mojarra's behavior in a webapp should be investigated to determine what causes this issue in portlets. Note that the changes in JSF 2.3 also break this showcase code . We need to consider a portlet filter which fixes this in order to avoid breaking backwards compatibility. Finally, when testing this in JSF 2.3, Mojarra must be patched as described by Neil in JAVASERVERFACES_SPEC_PUBLIC-790 . FACES-1798 and FACES-1797 are also related to this issue.
        Hide
        kyle.stiemann Kyle Stiemann added a comment -

        Duplicates FACES-2975.

        Show
        kyle.stiemann Kyle Stiemann added a comment - Duplicates FACES-2975 .

          People

          • Assignee:
            kyle.stiemann Kyle Stiemann
            Reporter:
            kyle.stiemann Kyle Stiemann
            Participants of an Issue:
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development

                Subcomponents