Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.0
-
Fix Version/s: 2.0.1
-
Component/s: Bridge
-
Labels:None
-
Environment:ICEfaces 2.0.0/2.0.1-SNAPSHOT from 2. March 2011
Mojarra 2.0.3/2.0.4/2.1.0-b5
Firefox 3.6.14/Chrome (Iron) 9.0.600.2/Safari 5.0.3/Internet Explorer 8.0.7601
Tomcat 7.0.6
Description
• The Ajax request looks OK to me, the action in the backing bean is called and the Ajax response seems to be OK too. But the page in the browser doesn't change at all.
• The bug is always reproducible using the same steps in the sample application. With Internet Explorer the bug happens later than in other browsers, it needs more clicks than the other browsers. With all other browsers I have tried, I was able to reproduce the problem using the same steps.
• If I disable DOM diffing using org.icefaces.render.auto=false in web.xml the bug doesn't occur. But this is not a workaround for me because then I can't use the ICEfaces 1.8 components which I need to use.
• The bug occurs with both h:commandButton and ace:pushButton.
• I don't get a JavaScript error in the browser
• Another guy has got the same problem in a totally different application.
• For me this is a blocker issue
I'll shortly provide a sample application and steps to reproduce via Micha Kiener as I can't make the sample public.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Note, however that the attached composition.zip does not exhibit the double click problem. The next step is to modify the pages so that this is reproduced.
This is not an ICEfaces bug. After modifying the sample to use h: components and adding f:ajax to one of the pages, the double click problem was reproducible with no ICEfaces jars in the application.
javax.faces.ViewState is not being sent on the first request after an ajax response, likely due to the presence of multiple forms; however ICEfaces contains a workaround for this.
This is fixed by upgrading to JSF 2.1.0. Updating the JSF .jar files had been tested earlier and did not appear to be successful. The test case must not have redeployed correctly at that time.
Fixed by upgrading to JSF 2.1.
I can confirm that this is fixed with Mojarra 2.1.0-b11
There are several factors in this test case. The root of the problem is that full page updates are occurring due to the ui:composition strategy. This results in a different viewRoot between ajax interactions so that the DOM is ignored and a full page update is returned. The attached pages composition.zip can be added to an existing test case to show the full page update.