ICEfaces
  1. ICEfaces
  2. ICE-10967

ace:dateTimeEntry onchange event not re-registered when component is re-initialized

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 4.1
          • Fix Version/s: 4.1.1
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            Liferay/Portlet but likely a webapp problem as well
          • Assignee Priority:
            P1

            Description

            Steps to Reproduce:

            1. Start Liferay Portal 7.0-B7

            2. Deploy the attached icefaces4-portlet-4.0.0-SNAPSHOT.war artifact to $LIFERAY_HOME/deploy

            3. Add the ICEfaces4 portlet to a new portal page

            4. Reload the page

            5. When the applicant form is rendered, click in the "Date of Birth" field in order to cause the calendar to popup.

            6. Enter an invalid date via the keyboard and press TAB: 02/30/2016

            7. Observe that the field turns red in the browser and in the server log, that only the RESTORE_VIEW, APPLY_REQUEST_VALUES, PROCESS_VALIDATIONS, and RENDER_RESPONSE phases were executed. In other words, the UPDATE_MODEL_VALUES and INVOKE_APPLICATION phases are skipped since the date of birth value is invalid.

            8. Using the mouse, click in the Date of Birth field in order to popup the calendar and then click on any date in the calendar so that the value is valid.

            9. Observe in the server log that all phases of the JSF lifecycle were executed.

            10. Click in the "Date of Birth" field and enter an invalid date via the keyboard and press TAB: 02/30/2016

            If the bug is fixed, then the behavior of step#7 should be observed, meaning that the UPDATE_MODEL_VALUES and INVOKE_APPLICATION phases are skipped.

            If the bug still exists, then an XHR will not be submitted at all and the field will not turn red.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Arturo Zambrano added a comment -

              Some observations so far:

              • This issue is not reproducible on a servlet environment.
              • The issue (not sending an ajax request when tabbing out) occurs after the very first ajax request done by the component, whether it was triggered by tabbing out of the text field or by clicking on a date on the calendar. In other words, it's not related to the validation error.
              • This seems to be a client-side only issue, where the onblur event listener is not working after the first time.
              • After the first ajax request the entire component markup is updated, but it seems like the onblur event is not applied correctly.

              I noticed that the scripts (i.e. inside <script> tags) with which the component is rendered when the page is loaded and the scripts with which the component is rendered after the first ajax update are slightly different. It seems like Liferay minifies the Javascript code when the page is loaded, but not on subsequent ajax requests. I don't know if this has anything to do with the issue.

              Show
              Arturo Zambrano added a comment - Some observations so far: This issue is not reproducible on a servlet environment. The issue (not sending an ajax request when tabbing out) occurs after the very first ajax request done by the component, whether it was triggered by tabbing out of the text field or by clicking on a date on the calendar. In other words, it's not related to the validation error. This seems to be a client-side only issue, where the onblur event listener is not working after the first time. After the first ajax request the entire component markup is updated, but it seems like the onblur event is not applied correctly. I noticed that the scripts (i.e. inside <script> tags) with which the component is rendered when the page is loaded and the scripts with which the component is rendered after the first ajax update are slightly different. It seems like Liferay minifies the Javascript code when the page is loaded, but not on subsequent ajax requests. I don't know if this has anything to do with the issue.
              Hide
              Permalink
              Neil Griffin added a comment -

              Hi Arturo,

              In order to see if this was a problem specifically with Liferay Portal, I deployed a pluto-specific version of the portlet to Apache Pluto. Sadly I wasn't able to try the test for this issue because I ran into another issue: ICE-10968. Just a thought, but focusing on solving ICE-10968 might help this issue move along as well.

              Neil

              Show
              Neil Griffin added a comment - Hi Arturo, In order to see if this was a problem specifically with Liferay Portal, I deployed a pluto-specific version of the portlet to Apache Pluto. Sadly I wasn't able to try the test for this issue because I ran into another issue: ICE-10968 . Just a thought, but focusing on solving ICE-10968 might help this issue move along as well. Neil
              Hide
              Permalink
              Arturo Zambrano added a comment -

              r47950: moved onchange event setup before call to re-initialize component in client

              This issue occurred simply because the onchange event wasn't being re-registered when the component was re-initialized. The code seemed too assume that there were not going to be full markup updates for the component, and, on Liferay, the full component markup was being updated at every request initiated by the component itself.

              This issue could also be reproduced on a servlet environment by having the component's 'rendered' attribute bound to a boolean property, which in turn is also bound to a checkbox, to control it. After undrendering and then rendering the component again, the onchange ajax event was never triggered again.

              Show
              Arturo Zambrano added a comment - r47950: moved onchange event setup before call to re-initialize component in client This issue occurred simply because the onchange event wasn't being re-registered when the component was re-initialized. The code seemed too assume that there were not going to be full markup updates for the component, and, on Liferay, the full component markup was being updated at every request initiated by the component itself. This issue could also be reproduced on a servlet environment by having the component's 'rendered' attribute bound to a boolean property, which in turn is also bound to a checkbox, to control it. After undrendering and then rendering the component again, the onchange ajax event was never triggered again.
              Hide
              Permalink
              Carmen Cristurean added a comment -

              ICEfaces4 trunk r47959: ran QA dateTimeEntry regressions (FF41, Chrome48, IE11), and showcase > dateTimeEntry tests (FF41, IE11), no issues found.

              Show
              Carmen Cristurean added a comment - ICEfaces4 trunk r47959: ran QA dateTimeEntry regressions (FF41, Chrome48, IE11), and showcase > dateTimeEntry tests (FF41, IE11), no issues found.
              Hide
              Permalink
              Carmen Cristurean added a comment - - edited

              Jenkins ICEfaces 4.1.1 Build #6: ran QA dateTimeEntry regressions, and showcase > dateTimeEntry tests (FF41, IE11, Chrome48), no issues found.

              Show
              Carmen Cristurean added a comment - - edited Jenkins ICEfaces 4.1.1 Build #6: ran QA dateTimeEntry regressions, and showcase > dateTimeEntry tests (FF41, IE11, Chrome48), no issues found.
              Hide
              Permalink
              Carmen Cristurean added a comment -

              Verified ICEfaces 4.1.1 Jenkins Build 6 (using liferay-faces-4.2.5.jar) with attached test case on Liferay 6.2/ Tomcat7.0.42, on FF41, Chrome48, IE11.

              At step7, when entering an invalid date and pressing TAB, the field does not become red, however in the logs, the UPDATE_MODEL_VALUES and INVOKE_APPLICATION phases are skipped. On submit, an "Invalid date format" message is rendered on page.

              Show
              Carmen Cristurean added a comment - Verified ICEfaces 4.1.1 Jenkins Build 6 (using liferay-faces- 4.2.5 .jar) with attached test case on Liferay 6.2/ Tomcat7.0.42, on FF41, Chrome48, IE11. At step7, when entering an invalid date and pressing TAB, the field does not become red, however in the logs, the UPDATE_MODEL_VALUES and INVOKE_APPLICATION phases are skipped. On submit, an "Invalid date format" message is rendered on page.
              Hide
              Permalink
              Carmen Cristurean added a comment - - edited

              Attaching test case used to verify this JIRA, using icefaces*-4.1.1 and liferay-faces*-4.2.5 jars.

              Show
              Carmen Cristurean added a comment - - edited Attaching test case used to verify this JIRA, using icefaces*-4.1.1 and liferay-faces*-4.2.5 jars.
              Hide
              Permalink
              Carmen Cristurean added a comment -

              Adding the liferay-faces-alloy-4.2.5-ga6.jar to the icefaces4-portlet-4.1.1.war test case fixes the dateTimeEntry field not turning red when entering an invalid date.

              Show
              Carmen Cristurean added a comment - Adding the liferay-faces-alloy-4.2.5-ga6.jar to the icefaces4-portlet-4.1.1.war test case fixes the dateTimeEntry field not turning red when entering an invalid date.

                People

                • Assignee:
                  Arturo Zambrano
                  Reporter:
                  Neil Griffin
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: