ICEfaces
  1. ICEfaces
  2. ICE-10769

icecore:singleSubmit - Issue with blockUiOnSubmit

    Details

    • Assignee Priority:
      P2
    • Support Case References:
    • Workaround Description:
      Cancel 'change' events for the textarea thus allowing the 'click' event from the 'Page 2' button to go out.

      Description

      When using the icecore:singleSubmit tag on the form and setting blockUiOnSubmit, it is preventing button clicks from executing their actions. This is only when editing an input field, and then clicking the button/link. The blur event for the input field is called correctly but this is preventing the button/link click from calling it's action.

      We have dealt with this issue in the past on 1.8.

        Activity

        Hide
        Arran Mccullough added a comment -

        Attached test case that shows this issue. Note: the icefaces.jar, icefaces-compat.jar and icefaces-ace.jar files need to be added into the war to show this issue.

        Steps:

        • Load welcomeICEfaces.jsf
        • In the input text field, add some values.
        • Without tabbing out of the field, click one of the commandButtons.
        • The expected behavior is that the navigation executed by the buttons is done. The issue is that the input field is submitted, but the button click action is not called.
        Show
        Arran Mccullough added a comment - Attached test case that shows this issue. Note: the icefaces.jar, icefaces-compat.jar and icefaces-ace.jar files need to be added into the war to show this issue. Steps: Load welcomeICEfaces.jsf In the input text field, add some values. Without tabbing out of the field, click one of the commandButtons. The expected behavior is that the navigation executed by the buttons is done. The issue is that the input field is submitted, but the button click action is not called.
        Hide
        Ken Fyten added a comment -

        Not clear why this issue is appearing again. This was resolved originally in ICE-4308 for EE 1.8.

        Show
        Ken Fyten added a comment - Not clear why this issue is appearing again. This was resolved originally in ICE-4308 for EE 1.8.
        Hide
        Mircea Toma added a comment -

        I cannot reproduce this issue. I did follow exactly the test instructions.

        Show
        Mircea Toma added a comment - I cannot reproduce this issue. I did follow exactly the test instructions.
        Hide
        Arran Mccullough added a comment -

        I went back and re-tested my sample. In Firefox, IE, and Chrome I see this issue. When ever the input field has focus and you click a button, the button action is not fired. It takes two clicks to get the buttons to work. I am testing with the current maintenance branch jars if that matters.

        Show
        Arran Mccullough added a comment - I went back and re-tested my sample. In Firefox, IE, and Chrome I see this issue. When ever the input field has focus and you click a button, the button action is not fired. It takes two clicks to get the buttons to work. I am testing with the current maintenance branch jars if that matters.
        Hide
        Mircea Toma added a comment -

        Once again I cannot reproduce this issue. Tested with all mentioned browser with successful results. There must be something else, maybe your environment, that makes this issue occur on your machine.

        Show
        Mircea Toma added a comment - Once again I cannot reproduce this issue. Tested with all mentioned browser with successful results. There must be something else, maybe your environment, that makes this issue occur on your machine.
        Hide
        Liana Munroe added a comment -

        Tested with ICEfaces EE-3.3.0 maintenance branch r45992 using attached test case, IE 11, FF 34, Chrome 45. I am able to confirm Arran's findings.
        If the input field has focus, the very first button click (does not matter which button) does not cause the navigation to occur. In the server log the text entered into the input is set but the navigation does not happen. A second press of the button is required.

        Show
        Liana Munroe added a comment - Tested with ICEfaces EE-3.3.0 maintenance branch r45992 using attached test case, IE 11, FF 34, Chrome 45. I am able to confirm Arran's findings. If the input field has focus, the very first button click (does not matter which button) does not cause the navigation to occur. In the server log the text entered into the input is set but the navigation does not happen. A second press of the button is required.
        Hide
        Mircea Toma added a comment - - edited

        The issue will occur only if the textarea's content was changed before clicking on the 'Page 2' button. In this use case the textarea will issue a singleSubmit on the 'change' event, the subsequent submit triggered by the 'click' event on the button is blocked by the blockUIOnSubmit feature. Since the submit that reaches the server is not triggered by the button the navigation is also not triggered.
        The obvious fix would be to modify the single submit capturing to not issue the submit on 'change' events (and actually we do that already for IE browsers). Now there might be other use cases where 'change' triggered submits are relied upon.

        Show
        Mircea Toma added a comment - - edited The issue will occur only if the textarea's content was changed before clicking on the 'Page 2' button. In this use case the textarea will issue a singleSubmit on the 'change' event, the subsequent submit triggered by the 'click' event on the button is blocked by the blockUIOnSubmit feature. Since the submit that reaches the server is not triggered by the button the navigation is also not triggered. The obvious fix would be to modify the single submit capturing to not issue the submit on 'change' events (and actually we do that already for IE browsers). Now there might be other use cases where 'change' triggered submits are relied upon.
        Hide
        Mircea Toma added a comment -

        A work around for this particular issue is maybe a better approach. To do that the 'change' events for textarea should be canceled and thus allowing the 'click' event from the button to go out. Only the page in the test application needs to be changed or that to:

        ...
        <ice:inputTextarea id="freeform" value="#{testBean.text}" onchange="if (event.stopPropagation) { event.stopPropagation() } else { event.returnValue = false; }"/>
        ...
        
        Show
        Mircea Toma added a comment - A work around for this particular issue is maybe a better approach. To do that the 'change' events for textarea should be canceled and thus allowing the 'click' event from the button to go out. Only the page in the test application needs to be changed or that to: ... <ice:inputTextarea id= "freeform" value= "#{testBean.text}" onchange= " if (event.stopPropagation) { event.stopPropagation() } else { event.returnValue = false ; }" /> ...
        Hide
        Liana Munroe added a comment -

        Tested with ICEfaces EE-3.3.0 maintenance branch r46929. Verified work-around using test case and Tomcat 8, IE 11, 10, 9, 8, 7, FF 43, Chrome 47.

        Show
        Liana Munroe added a comment - Tested with ICEfaces EE-3.3.0 maintenance branch r46929. Verified work-around using test case and Tomcat 8, IE 11, 10, 9, 8, 7, FF 43, Chrome 47.

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: