Details
Bug
Major
Description
Under certain conditions, the ViewState may not get written to the page/form which causes a problem when navigating. The typical result is that every second click of a button that triggers navigation doesn't appear to work. The problematic behaviour is actually seen in Mojarra 2.0.2 without ICEfaces. The conditions required are:
The page starts with the XML preamble like: <?xml version="1.0" encoding="UTF-8"?>
The form does not have a specific id set on it: <h:form prependId="false">
The button is Ajax-enabled with render all:
<h:commandButton id="navButton" value="Go to Page 2" action="page02">
<f:ajax render="@all"/>
</h:commandButton>
So given a couple of simple pages like this that navigate back and forth to each other:
<?xml version="1.0"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<h:head>
<title>Ajax Navigation</title>
</h:head>
<h:body>
<h:form prependId="false">
<p>
<h:commandButton id="navButton" value="Go to Page 2" action="page02" >
<f:ajax render="@all"/>
</h:commandButton>
</p>
</h:form>
</h:body>
</html>
will result in every second click failing.
The page starts with the XML preamble like: <?xml version="1.0" encoding="UTF-8"?>
The form does not have a specific id set on it: <h:form prependId="false">
The button is Ajax-enabled with render all:
<h:commandButton id="navButton" value="Go to Page 2" action="page02">
<f:ajax render="@all"/>
</h:commandButton>
So given a couple of simple pages like this that navigate back and forth to each other:
<?xml version="1.0"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<h:head>
<title>Ajax Navigation</title>
</h:head>
<h:body>
<h:form prependId="false">
<p>
<h:commandButton id="navButton" value="Go to Page 2" action="page02" >
<f:ajax render="@all"/>
</h:commandButton>
</p>
</h:form>
</h:body>
</html>
will result in every second click failing.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Re-assigning to Mircea as a "todo" item - please submit a bug to the Mojarra tracking system regarding this behaviour.
Show
Deryk Sinotte
added a comment - Re-assigning to Mircea as a "todo" item - please submit a bug to the Mojarra tracking system regarding this behaviour.
Created issue in Mojarra's bug tracking system: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1715
Show
Mircea Toma
added a comment - Created issue in Mojarra's bug tracking system: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1715
Trying to fix this issue on the ICEfaces side. Recreating the javax.faces.ViewState input elements on the client side seems to be a much easier fix.
Show
Mircea Toma
added a comment - Trying to fix this issue on the ICEfaces side. Recreating the javax.faces.ViewState input elements on the client side seems to be a much easier fix.
The solution applied adds the hidden input element holding the view state key into the forms that miss it after they are updated.
Show
Mircea Toma
added a comment - The solution applied adds the hidden input element holding the view state key into the forms that miss it after they are updated.
The problem seems to be that under the above conditions, the id of the form oscillates between two different values and the client code cannot properly write out the ViewState update into the form because it can't find it. If you note the workarounds, specifying a specific id for the form helps prevent this. So does removing the <?xml line (but I can't understand why this impacts the behaviour at all yet). You can also choose to render a specific subtree rather than @all and that should work as well.
Since this problem occurs without ICEfaces in Mojarra 2.0.2, we aren't going to investigate fixing it any further. We may want to consider opening a bug with the Mojarra project if the problem persists in the current Mojarra trunk.