ICEfaces
  1. ICEfaces
  2. ICE-2893

CommandButton action not always firing when button is clicked

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 1.6.2, 1.7RC1
    • Fix Version/s: 1.8.2
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Windows XP, JBOSS 4.2.2 GA

      Description

      I have a simple ICEFaces application running on JBOSS 4.2.2 GA using its supplied JSF 1.2 implementation. The app has a single JSPX - a login page. This page has the following:
      1. <ice:form partialSubmit="true"
      2. <ice:inputText for User Name
      3. <ice:inputText for Password
      4. <ice:commandButton with action set to loginBean.doLogin
      5. <ice:messages globalOnly="true"

      The application has System.out.println statements at:
      1. The 'afterPhase' and 'beforePhase' methods on a PhaseListener
      2. The beginning of the 'doLogin' method, and the beginning of each validation method.

      The loginBean method 'doLogin' performs validations, and if any problems are found, a global FacesMessage is added to the FacesContext, and 'null' is returned.
      The following validations are performed:
      1. Both User Name and Password are required
      2. User Name must be 4-20 characters in length
      3. Password must be 4-12 characters in length
      4. The User Name must = rmoyers, and the Password must = letmein
      Note: none of these validations are being done with the validation framework - they are all 'application' level validations. The reason I chose to do this could be another issue, but I can live with not using the validation framework.

      Here is the scenario which leads to the problem:
      1. Start the app, and enter just 'b' in User Name. Do not tab out of User Name. Leave Password blank. Use the mouse to Click the Login button.
      2. The 'doLogin' method is correctly fired, and it correctly adds two messages (User Name too short, and Password required).
      3. The form is correctly rendered with the two messages.
      4. Add the letter 'o' to the end of the User Name, making it 'bo'. Do NOT tab out of User Name, and use the mouse to Click the Login button.
      5. The 'doLogin' method DOES NOT fire. Messages on the console show that all 6 JSF lifecycle phases are invoked.
      6. Press the Login button again, and the 'doLogin' method DOES fire. The net effect is that the user must click the Login button TWICE. This is 100% reproducable.


      Here are some things that make it work correctly:
      1. In step 4, if you tab out of the User Name (after adding the letter 'o'), then click the Login button, everything works as expected.
      2. In step 4, if you navigate away from the browser (after adding the letter 'o'), then navigate back, then click the Login button, everything works as expected.
      3. With <ice:form partialSubmit="false", everything works correctly.


      The same behavior exists in both 1.6.2 and 1.7.0. I can get the simple project to you if you give me instructions on how to do it.


        Issue Links

          Activity

          Hide
          Sheng Gu added a comment -

          Hi Adnan,

          I have the problem when ice:inputRichText and ice:selectInputText are the same page, not ice:selectInputDate. I found the problem on 1.8.0, but I didn't test it on 1.8.1. Thanks.

          Show
          Sheng Gu added a comment - Hi Adnan, I have the problem when ice:inputRichText and ice:selectInputText are the same page, not ice:selectInputDate. I found the problem on 1.8.0, but I didn't test it on 1.8.1. Thanks.
          Hide
          Sheng Gu added a comment -

          Hi Adnan,

          How to reopen this JIRA? I found that you used selectInputDate in your test snippet. It should be selectInputText. Thanks.

          Show
          Sheng Gu added a comment - Hi Adnan, How to reopen this JIRA? I found that you used selectInputDate in your test snippet. It should be selectInputText. Thanks.
          Hide
          John Jones added a comment -

          Our product can reproduce this problem similarly to how the original description of this error is stated. We are using just-ice 1.8.1 and myfaces 1.1.5, synchronous mode.

          We have found that this is only reproducible when the blockUIOnSubmit parameter is set to "true" (the documentation also mentions this is the default state). The theory is that the onblur javascript (on the component) partially submits the "wait-cursor" http request first, which blocks the actual request from posting when the button is clicked. Any listeners attached to the input component are fired because the partial submit is successful, however since UI interaction is blocked and the button click is never posted, the action method is never fired.

          When we set the com.icesoft.faces.blockUIOnSubmit context parameter (in the web.xml file) to false, the UI is not blocked and the partial submits on the component and the button click are both successfully posted. While this workaround resolves the issue, the application now does not prevent "happy clicking".

          Show
          John Jones added a comment - Our product can reproduce this problem similarly to how the original description of this error is stated. We are using just-ice 1.8.1 and myfaces 1.1.5, synchronous mode. We have found that this is only reproducible when the blockUIOnSubmit parameter is set to "true" (the documentation also mentions this is the default state). The theory is that the onblur javascript (on the component) partially submits the "wait-cursor" http request first, which blocks the actual request from posting when the button is clicked. Any listeners attached to the input component are fired because the partial submit is successful, however since UI interaction is blocked and the button click is never posted, the action method is never fired. When we set the com.icesoft.faces.blockUIOnSubmit context parameter (in the web.xml file) to false, the UI is not blocked and the partial submits on the component and the button click are both successfully posted. While this workaround resolves the issue, the application now does not prevent "happy clicking".
          Hide
          Christophe Taverne added a comment -

          Same problem than John,

          regards.

          Show
          Christophe Taverne added a comment - Same problem than John, regards.
          Hide
          Ken Fyten added a comment -

          This issue duplicates ICE-4308.

          Show
          Ken Fyten added a comment - This issue duplicates ICE-4308 .

            People

            • Assignee:
              Unassigned
              Reporter:
              Robert Moyers
            • Votes:
              5 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: