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
        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 ]
        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: