ICEfaces
  1. ICEfaces
  2. ICE-11228

ace:submitMonitor - Monitor blocking button click

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-3.3.0.GA_P03, EE-4.1.0.GA, EE-3.3.0.GA_P04, 4.2.BETA
          • Fix Version/s: 4.2, EE-3.3.0.GA_P05
          • Component/s: ACE-Components, ICE-Components
          • Labels:
            None
          • Environment:
            EE 3.3.0 P03, P04
          • Assignee Priority:
            P1
          • Support Case References:
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
             - Use the standard JSF components.
             - Remove the ajax update or partialSubmit=true from the input field component.
            Show
             - Use the standard JSF components.  - Remove the ajax update or partialSubmit=true from the input field component.

            Description

            The ace:submitMonitor is blocking the submit/click of a button when focus is in an input field.

            The input field uses an ajax update or partialSubmit=true. When the field has focus and a button is clicked quickly, the actionLisetner for the button isn't called. If the click on the button happens slowly, the listener is called.

            This looks to be an issue since the P03 release as the P02 release doesn't show this issue. Also the standard JSF components (h:commandButton, h:inputText) don't show this issue.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached test case that shows this issue with the ICE and ACE components.

              Steps:

              • Load welcomeICEfaces.jsf
              • Add some text to the input field under the submit button.
              • Keeping focus in the input field, quickly click the Submit button.
              • If the action listener is called, it will be shown in the logs. On a very quick click, this isn't shown.
              Show
              Arran Mccullough added a comment - Attached test case that shows this issue with the ICE and ACE components. Steps: Load welcomeICEfaces.jsf Add some text to the input field under the submit button. Keeping focus in the input field, quickly click the Submit button. If the action listener is called, it will be shown in the logs. On a very quick click, this isn't shown.
              Hide
              Permalink
              Arran Mccullough added a comment -

              This is also an issue on the latest ICEfaces 4 code base (ACE comps).

              Show
              Arran Mccullough added a comment - This is also an issue on the latest ICEfaces 4 code base (ACE comps).
              Hide
              Permalink
              Ken Fyten added a comment -

              This is a feature of the submitMonitor if "blockUI" is configured.

              As per the TLD Doc:

              When enabled, display a translucent overlay on a portion of the window, and only show the submitMonitor UI when the connection is not idle and a submit is underway. This property specifies on what portion of the window to show the overlay: "@all" means the whole document body, "@source" means only over the component that originated the request, or a for style component search string may be given to specify a component. Finally, "@none" means to disable the overlay and have the submitMonitor UI always present where it has been placed in the page. Default = '@all'.

              If the application wants to allow further user interaction while the ajax submit is executing, they should configure blockUI="@none".

              Show
              Ken Fyten added a comment - This is a feature of the submitMonitor if "blockUI" is configured. As per the TLD Doc: When enabled, display a translucent overlay on a portion of the window, and only show the submitMonitor UI when the connection is not idle and a submit is underway. This property specifies on what portion of the window to show the overlay: "@all" means the whole document body, "@source" means only over the component that originated the request, or a for style component search string may be given to specify a component. Finally, "@none" means to disable the overlay and have the submitMonitor UI always present where it has been placed in the page. Default = '@all'. If the application wants to allow further user interaction while the ajax submit is executing, they should configure blockUI="@none".
              Hide
              Permalink
              Mircea Toma added a comment -

              I cannot reproduce this issue. I ran the test with Safari, Firefox and Chrome. Is there anything else I need to do that maybe was not mentioned in the description?

              Show
              Mircea Toma added a comment - I cannot reproduce this issue. I ran the test with Safari, Firefox and Chrome. Is there anything else I need to do that maybe was not mentioned in the description?
              Hide
              Permalink
              Arran Mccullough added a comment -

              The key to reproduce the issue is to very quickly click the button via the mouse. With a slower more deliberate click, this isn't reproducible. It took me a few times to get the quick click down but once I saw it I can reproduce it every time.

              Show
              Arran Mccullough added a comment - The key to reproduce the issue is to very quickly click the button via the mouse. With a slower more deliberate click, this isn't reproducible. It took me a few times to get the quick click down but once I saw it I can reproduce it every time.
              Hide
              Permalink
              Ken Fyten added a comment -

              Okay, Arran stepped me through it.

              The issue occurs when the focus is originally on the text entry field that has been edited (and has an ace:ajax submit or partialSubmit enabled on it). When you then click on the submit button, the ace:ajax submit from the text input seems to interfering with the normal operation of the ace:submitMonitor. The way the test is written, the submitMonitor should not even be triggered by the text entry ajax submit, so it's a bit strange. If you click the submit button and hold it down for a second or so (presumably until the ace:ajax submit from the text entry completes), it works correctly and the submitButton event is fired on the server.

              Seems like an impedance mismatch between the dom events we're using to trigger submitMonitor on the button, and the actual submit. The submit shouldn't occur until the mouse button on the button is released, and neither should the submitMonitor. Having an in-progress ajax submit off of the onblur on the textEntry should have NO impact, since the submitMonitor is configured with "for=submitButton" only.

              To reproduce:

              1. enter some text in the textentry, leave focus on textEntry
              2. Click the submitButton normally (fast mouse button down and release).
              3. No event logged in the server log for the submitButton event == FAIL.
              1. enter some text in the textentry, leave focus on textEntry
              2. Click and HOLD the mouse button down over the submitButton for a second, then release.
              3. Submitbutton event logged in the server log == PASS.

              You can also disable the ace:ajax submit on the textEntry and it will work everytime, so their is some unexpected interaction between the ace:submitMonitor on the submitButton, and the ace:ajax submit on the text entry.

              Show
              Ken Fyten added a comment - Okay, Arran stepped me through it. The issue occurs when the focus is originally on the text entry field that has been edited (and has an ace:ajax submit or partialSubmit enabled on it). When you then click on the submit button, the ace:ajax submit from the text input seems to interfering with the normal operation of the ace:submitMonitor. The way the test is written, the submitMonitor should not even be triggered by the text entry ajax submit, so it's a bit strange. If you click the submit button and hold it down for a second or so (presumably until the ace:ajax submit from the text entry completes), it works correctly and the submitButton event is fired on the server. Seems like an impedance mismatch between the dom events we're using to trigger submitMonitor on the button, and the actual submit. The submit shouldn't occur until the mouse button on the button is released, and neither should the submitMonitor. Having an in-progress ajax submit off of the onblur on the textEntry should have NO impact, since the submitMonitor is configured with "for=submitButton" only. To reproduce: enter some text in the textentry, leave focus on textEntry Click the submitButton normally (fast mouse button down and release). No event logged in the server log for the submitButton event == FAIL. enter some text in the textentry, leave focus on textEntry Click and HOLD the mouse button down over the submitButton for a second, then release. Submitbutton event logged in the server log == PASS. You can also disable the ace:ajax submit on the textEntry and it will work everytime, so their is some unexpected interaction between the ace:submitMonitor on the submitButton, and the ace:ajax submit on the text entry.
              Hide
              Permalink
              Mircea Toma added a comment -

              I finally managed to reproduce the problem by slowing down the response from the server.

              Show
              Mircea Toma added a comment - I finally managed to reproduce the problem by slowing down the response from the server.
              Hide
              Permalink
              Mircea Toma added a comment -

              Modified the overriding submit function to exercise the submit lock only when the triggering element is monitored.

              Show
              Mircea Toma added a comment - Modified the overriding submit function to exercise the submit lock only when the triggering element is monitored.

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: