Details
-
Type: Bug
-
Status: Closed
-
Priority: 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.
- 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 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #32994 | Tue Jan 08 14:46:37 MST 2013 | mircea.toma | |
Files Changed | ||||
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 | |
Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/core/src/main/javascript/blockui.js
|
Mircea Toma
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Attached test case that shows the issue.
Steps: