ICEfaces
  1. ICEfaces
  2. ICE-9741

ace:autoCompleteEntry TextChangeListener firing Twice

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P01
    • Fix Version/s: 4.0.BETA, EE-3.3.0.GA_P02, 4.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Tomcat 7
    • Assignee Priority:
      P1

      Description

      I have an ace:autoCompleteEntry component configured as follows:

                      <ace:autoCompleteEntry id="meCode1"
                              textChangeListener="#{crListDataTableBean1.getMeCodeAcTxtChng}"
                              valueChangeListener="#{crListDataTableBean1.getMeCode1AcList}"
                              listValue="#{crListDataTableBean1.meCodeAutoCompleteList}"
                              listVar="me" rows="10"
                              value="#{crListDataTableBean1.formData.meCode1}"
                              filterBy="#{me.stringKey}" filterMatchMode="none">
                              <f:facet name="row">
                                  <h:panelGrid columns="2">
                                      <h:outputText value="#{me.stringKey}" />
                                      <h:outputText value="#{me.desc}" />
                                  </h:panelGrid>
                              </f:facet>
                              <f:attribute name="SOURCE" value="test"/>
                              <f:validator validatorId="test.validator" />
                              <ace:ajax render="@form" event="submit"/>
                              <ace:ajax render="@form" event="blur"/>
                      </ace:autoCompleteEntry>

      When I enter text and tab out, I see the textChangeListener executed twice. In general, there appear to be 3 submits to the server instead of the expected 2. This could be resulting in the Validator message being cleared when you expect to see it.

      Also, when this component is placed in an ace:dataTable with an ace:autoCompleteEntry component in the adjacent column, there are some observations seen related to focus:

      - If type in field, select an entry from the drop-down, move to the next autoCompleteEntry field, type ‘0’ and the 0 appears on the end of the previous column field. The focus appears to be going back to the non-previous field after selecting a valid code.

      I have attached a Test application with ace:autoCompleteEntry tags in adjacent columns of an ace:dataTable.
      1. screenshot-ice9741-1.png
        178 kB
      2. screenshot-ice9741-2.png
        170 kB

        Activity

        Hide
        Brad Kroeger added a comment -

        Please test again with some invalid input and then tabbing out of the field. Input such as 'asdf' (the validator checks for a number). If everything appears to be working as expected after that, I will step you through the client application.

        Show
        Brad Kroeger added a comment - Please test again with some invalid input and then tabbing out of the field. Input such as 'asdf' (the validator checks for a number). If everything appears to be working as expected after that, I will step you through the client application.
        Hide
        Arturo Zambrano added a comment -

        I couldn't reproduce the issues as described, but I did see an issue when submitting an invalid value. An extra request is being made when the component is marked invalid.

        Show
        Arturo Zambrano added a comment - I couldn't reproduce the issues as described, but I did see an issue when submitting an invalid value. An extra request is being made when the component is marked invalid.
        Hide
        Arturo Zambrano added a comment -

        Committed fix to 3.3 EE maintenance branch and 4.0 trunk at revisions 39428 and 39429.

        There were two separate problems. The first one was that the 'enter' keypress event wasn't properly prevented from propagation, and the second one was that when the component is marked invalid, the addition of the 'aria-invalid' attribute and the ui-state-error class name to the input element causes a full markup update of the component, which in turn was triggering an unwanted onblur event. All this was fixed by properly preventing the event from propagating and by disposing the timeout functions and event listeners of the previous instance.

        Show
        Arturo Zambrano added a comment - Committed fix to 3.3 EE maintenance branch and 4.0 trunk at revisions 39428 and 39429. There were two separate problems. The first one was that the 'enter' keypress event wasn't properly prevented from propagation, and the second one was that when the component is marked invalid, the addition of the 'aria-invalid' attribute and the ui-state-error class name to the input element causes a full markup update of the component, which in turn was triggering an unwanted onblur event. All this was fixed by properly preventing the event from propagating and by disposing the timeout functions and event listeners of the previous instance.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Brad Kroeger
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: