ICEfaces
  1. ICEfaces
  2. ICE-8846

blockUiOnSubmit - Keyboard events aren't blocked

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.0.0.GA_P01, 3.2, EE-3.2.0.BETA
    • Fix Version/s: EE-3.2.0.GA
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      All
    • Assignee Priority:
      P2
    • Salesforce Case Reference:

      Description

      A few issues are seen when using the blockUiOnSubmit parameter:

       - If you hit the enter key twice, two actions will be seen. These events seem to be queued and will fire one after the other. This behavior can be seen with the ice:inputText field with an action/actionListener defined and also with ice/h:commandButtons.

       - While processing is happening, the ui becomes blocked. This prevents any mouse clicks from happening. It does not however prevent the keyboard events. While the ui blocker is on I can tab through the components and even select them via the kayboard, there by queuing up more calls.

        Activity

        Arran Mccullough created issue -
        Arran Mccullough made changes -
        Field Original Value New Value
        Salesforce Case Reference 5007000000QW8oVAAT
        Hide
        Arran Mccullough added a comment -

        Attached test case that shows the issue.

        Steps:

        • Load welcomeICEfaces.jsf and keep and eye on the server logs.
        • Focus into the input field and enter in some text.
        • Hit the enter key twice, one event will be fired, once that event is done, another event is called.
        • The same can be seen if you focus on the commandButtons.
        • There is a 3 second delay in the processing, while this is happening you can tab through the various input components.
        Show
        Arran Mccullough added a comment - Attached test case that shows the issue. Steps: Load welcomeICEfaces.jsf and keep and eye on the server logs. Focus into the input field and enter in some text. Hit the enter key twice, one event will be fired, once that event is done, another event is called. The same can be seen if you focus on the commandButtons. There is a 3 second delay in the processing, while this is happening you can tab through the various input components.
        Arran Mccullough made changes -
        Attachment Case11844Example.zip [ 15289 ]
        Attachment Case11844ExampleWAR.zip [ 15290 ]
        Arran Mccullough made changes -
        Description A few issues are seen when using the blockUiOnSubmit parameter:

         - If you hit the enter key twice, two actions will be seen. These events seem to be queued and will fire one after the other. This behavior can be seen with the ice:inputText field with an action/actionListener defined and also with ice/h:commandButtons.

         - While processing is happening, the ui becomes blocked. This prevents any mouse clicks from happening. It does not however prevent the keyboard events. While the ui blocker is on I can tab through the components and even select them via the kayboard, there by queuing up more calls.
        A few issues are seen when using the blockUiOnSubmit parameter:

         - If you hit the enter key twice, two actions will be seen. These events seem to be queued and will fire one after the other. This behavior can be seen with the ice:inputText field with an action/actionListener defined and also with ice/h:commandButtons.

         - While processing is happening, the ui becomes blocked. This prevents any mouse clicks from happening. It does not however prevent the keyboard events. While the ui blocker is on I can tab through the components and even select them via the keyboard, there by queuing up more calls.
        Ken Fyten made changes -
        Fix Version/s EE-3.2.0.GA [ 10332 ]
        Description A few issues are seen when using the blockUiOnSubmit parameter:

         - If you hit the enter key twice, two actions will be seen. These events seem to be queued and will fire one after the other. This behavior can be seen with the ice:inputText field with an action/actionListener defined and also with ice/h:commandButtons.

         - While processing is happening, the ui becomes blocked. This prevents any mouse clicks from happening. It does not however prevent the keyboard events. While the ui blocker is on I can tab through the components and even select them via the keyboard, there by queuing up more calls.
        A few issues are seen when using the blockUiOnSubmit parameter:

         - If you hit the enter key twice, two actions will be seen. These events seem to be queued and will fire one after the other. This behavior can be seen with the ice:inputText field with an action/actionListener defined and also with ice/h:commandButtons.

         - While processing is happening, the ui becomes blocked. This prevents any mouse clicks from happening. It does not however prevent the keyboard events. While the ui blocker is on I can tab through the components and even select them via the kayboard, there by queuing up more calls.
        Assignee Mircea Toma [ mircea.toma ]
        Assignee Priority P2 [ 10011 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #32994 Tue Jan 08 14:46:37 MST 2013 mircea.toma ICE-8846 Stop event bubbling and cancel default actions for all the input elements thus avoiding to trigger the callbacks that are registered with the enclosing form.
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/javascript/blockui.js
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #32998 Tue Jan 08 16:01:51 MST 2013 mircea.toma ICE-8846 Fixed log message for discarded events.
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/javascript/blockui.js
        Hide
        Mircea Toma added a comment - - edited

        The applied fix stops the event bubbling and cancels the default actions for all the input elements thus avoiding to trigger the callbacks that are registered with the enclosing form (such as the ones created by ice.captureEnterKey feature).

        Show
        Mircea Toma added a comment - - edited The applied fix stops the event bubbling and cancels the default actions for all the input elements thus avoiding to trigger the callbacks that are registered with the enclosing form (such as the ones created by ice.captureEnterKey feature).
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: