Details
Description
1. <ice:form partialSubmit="true"
2. <ice:inputText for User Name
3. <ice:inputText for Password
4. <ice:commandButton with action set to loginBean.doLogin
5. <ice:messages globalOnly="true"
The application has System.out.println statements at:
1. The 'afterPhase' and 'beforePhase' methods on a PhaseListener
2. The beginning of the 'doLogin' method, and the beginning of each validation method.
The loginBean method 'doLogin' performs validations, and if any problems are found, a global FacesMessage is added to the FacesContext, and 'null' is returned.
The following validations are performed:
1. Both User Name and Password are required
2. User Name must be 4-20 characters in length
3. Password must be 4-12 characters in length
4. The User Name must = rmoyers, and the Password must = letmein
Note: none of these validations are being done with the validation framework - they are all 'application' level validations. The reason I chose to do this could be another issue, but I can live with not using the validation framework.
Here is the scenario which leads to the problem:
1. Start the app, and enter just 'b' in User Name. Do not tab out of User Name. Leave Password blank. Use the mouse to Click the Login button.
2. The 'doLogin' method is correctly fired, and it correctly adds two messages (User Name too short, and Password required).
3. The form is correctly rendered with the two messages.
4. Add the letter 'o' to the end of the User Name, making it 'bo'. Do NOT tab out of User Name, and use the mouse to Click the Login button.
5. The 'doLogin' method DOES NOT fire. Messages on the console show that all 6 JSF lifecycle phases are invoked.
6. Press the Login button again, and the 'doLogin' method DOES fire. The net effect is that the user must click the Login button TWICE. This is 100% reproducable.
Here are some things that make it work correctly:
1. In step 4, if you tab out of the User Name (after adding the letter 'o'), then click the Login button, everything works as expected.
2. In step 4, if you navigate away from the browser (after adding the letter 'o'), then navigate back, then click the Login button, everything works as expected.
3. With <ice:form partialSubmit="false", everything works correctly.
The same behavior exists in both 1.6.2 and 1.7.0. I can get the simple project to you if you give me instructions on how to do it.
Issue Links
- duplicates
-
ICE-4308
"blockUIOnSubmit=true" stops button press from firing Action event
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Fix Version/s | 1.8.2 [ 10190 ] |
Hi there,
I have the same problem when the ice:selectInputText and ice:inputRichText components appear on the same page. At this situation, submit button needs to be clicked twice, then contents can be submitted. Thanks.
| Assignee | Adnan Durrani [ adnan.durrani ] |
Robert it would be good if you can attach a war file so we can reproduce it.
We have created a test case using following snippet and it always fires actionListener.
<ice:form partialSubmit="true">
<ice:messages globalOnly="true" />
<ice:panelGrid columns="2">
<ice:outputText value="User Name"/>
<ice:inputText value="#
" />
<ice:outputText value="Password"/>
<ice:inputText value="#
" />
<ice:commandButton value="Login" actionListener="#
"/>
</ice:panelGrid>
</ice:form>
However there is a case when you put required="true" on inputText component and blur out the text field without entering any value then the actionListener will be prevented to get fired. Which is fine if validation fails. As you are setting "globalOnly" to "true" on "messages", so you might getting some framework validation errors which you are not aware of.
You can either test you app by removing globalOnly="true" from the messages or set the immediate="true" on ice:commandButton.
Hi all, this is Robert Moyers - the creator of this bug. I remember this was annoying.
I no longer work on the contract for which this bug was found. The simple app is on the customer's computer, and I no longer have access to it. I have asked a programmer still there to follow up, and attach the small application. He is:
Will Turner
wturner@rfdinc.com
| Status | Open [ 1 ] | In Progress [ 3 ] |
Hi Sheng,
I have tested following snippet with potential 1.8.2 branch and cannot reproduce it.
<ice:form partialSubmit="true">
<ice:messages />
<ice:panelGrid columns="2">
<ice:inputRichText value="#
"/>
<ice:selectInputDate value="#
"/>
<ice:outputText value="#
" />
<ice:commandButton value="Login" actionListener="#
"/>
</ice:panelGrid>
</ice:form>
Please provide a testcase and reopen this case.
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolution | Cannot Reproduce [ 5 ] |
Hi Adnan,
I have the problem when ice:inputRichText and ice:selectInputText are the same page, not ice:selectInputDate. I found the problem on 1.8.0, but I didn't test it on 1.8.1. Thanks.
Hi Adnan,
How to reopen this JIRA? I found that you used selectInputDate in your test snippet. It should be selectInputText. Thanks.
Our product can reproduce this problem similarly to how the original description of this error is stated. We are using just-ice 1.8.1 and myfaces 1.1.5, synchronous mode.
We have found that this is only reproducible when the blockUIOnSubmit parameter is set to "true" (the documentation also mentions this is the default state). The theory is that the onblur javascript (on the component) partially submits the "wait-cursor" http request first, which blocks the actual request from posting when the button is clicked. Any listeners attached to the input component are fired because the partial submit is successful, however since UI interaction is blocked and the button click is never posted, the action method is never fired.
When we set the com.icesoft.faces.blockUIOnSubmit context parameter (in the web.xml file) to false, the UI is not blocked and the partial submits on the component and the button click are both successfully posted. While this workaround resolves the issue, the application now does not prevent "happy clicking".
Same problem than John,
regards.
| Resolution | Cannot Reproduce [ 5 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
| Assignee | Adnan Durrani [ adnan.durrani ] |
| Status | Reopened [ 4 ] | Closed [ 6 ] |
| Resolution | Duplicate [ 3 ] |
Hi, can you attach the project to the JIRA as a .zip archive?