Details
Bug
Major
Description
When using the patched Mojarra 2.1.3 jar it is not possible to clear out a non-ajax enabled h:inputText field. With the regular Mojarra 2.1.3 jar this is possible with the same code.
My test also shows and issue with an ajax enabled input field not being cleared. Its possible that this is an issue with the patched jar and the code that is being called to clear/reset all input fields on the form.
-
Hide
-
-
META-INF/MANIFEST.MF
-
META-INF/context.xml
-
WEB-INF/classes/com/.../example/Item.class
-
WEB-INF/classes/.../example/TestBean.class
-
WEB-INF/lib/commons-beanutils.jar
-
WEB-INF/lib/commons-collections.jar
-
WEB-INF/lib/commons-digester.jar
-
WEB-INF/lib/commons-logging.jar
-
WEB-INF/lib/icefaces-ee-ace.jar
-
WEB-INF/lib/icefaces-ee-compat.jar
-
WEB-INF/lib/icefaces-ee.jar
-
WEB-INF/lib/javax.faces.jar
-
WEB-INF/web.xml
-
welcomeICEfaces.xhtml
-
-
-
-
Hide
-
-
META-INF/MANIFEST.MF
-
META-INF/error-include.xhtml
-
META-INF/facelet-dev-debug.xml
-
META-INF/facelet-dev-error.xml
-
META-INF/html_basic.tld
-
META-INF/jsf_core.tld
-
META-INF/mojarra-jsf-api-probe-provider.xml
-
META-INF/mojarra_ext.taglib.xml
-
META-INF/mojarra_ext.tld
-
META-INF/resources/.../jsf-uncompressed.js
-
META-INF/resources/javax.faces/jsf.js
-
META-INF/.../com.sun.faces.spi.injectionprovider
-
META-INF/.../javax.servlet.ServletContainerInitializer
-
com/sun/faces/LogStrings.properties
-
com/sun/faces/LogStrings_de.properties
-
com/sun/faces/LogStrings_es.properties
-
com/sun/faces/LogStrings_fr.properties
-
com/sun/faces/LogStrings_ja.properties
-
com/sun/faces/LogStrings_ko.properties
-
com/sun/.../LogStrings_pt_BR.properties
-
com/sun/.../LogStrings_zh_CN.properties
-
com/sun/.../LogStrings_zh_HK.properties
-
com/sun/.../LogStrings_zh_TW.properties
-
com/sun/faces/RIConstants.class
-
com/sun/faces/XMLSchema.dtd
-
com/sun/.../ActionListenerImpl.class
-
com/sun/.../ApplicationAssociate$1.class
-
com/sun/.../ApplicationAssociate.class
-
com/sun/.../ApplicationFactoryImpl.class
-
com/sun/.../ApplicationImpl$1.class
-
-
Activity
Attached test case to reproduce issue.
As near as I can figure at the moment, the problem does seem to exist in the patched version of jsf.js that we have in 2.1.3. In there is a clone attributes function that we modified. In that function, we altered how attributes are copied. Here is the section that deals with input style elements specifically:
var isInputElement = target.nodeName.toLowerCase() === 'input';
var propertyNames = isInputElement ? coreElementProperties.concat(inputElementProperties) : coreElementProperties;
for (var iIndex = 0, iLength = propertyNames.length; iIndex < iLength; iIndex++) {
var propertyName = propertyNames[iIndex];
var attributeName = propertyToAttribute(propertyName);
if (sourceAttributeDetector(attributeName)) {
var newValue = source[propertyName];
var oldValue = target[propertyName];
if (oldValue != newValue) {
target[propertyName] = newValue;
}
} else if (targetAttributeDetector(attributeName)) {
//setting property to '' seems to be the only cross-browser method for removing an attribute
target[propertyName] = '';
}
}
From my testing, I don't see either the sourceAttributeDetector() or targetAttributeDetector() conditions being satisfied which would mean the attribute never gets updated. This aligns with the fact that the response coming back from the server is correct in that the value has been cleared.
Since this code is similar to the code we passed to the Mojarra team for inclusion in JSF for 2.1.15, we should make sure we don't have the same problem there.
Show
Deryk Sinotte
added a comment - - edited As near as I can figure at the moment, the problem does seem to exist in the patched version of jsf.js that we have in 2.1.3. In there is a clone attributes function that we modified. In that function, we altered how attributes are copied. Here is the section that deals with input style elements specifically:
var isInputElement = target.nodeName.toLowerCase() === 'input';
var propertyNames = isInputElement ? coreElementProperties.concat(inputElementProperties) : coreElementProperties;
for ( var iIndex = 0, iLength = propertyNames.length; iIndex < iLength; iIndex++) {
var propertyName = propertyNames[iIndex];
var attributeName = propertyToAttribute(propertyName);
if (sourceAttributeDetector(attributeName)) {
var newValue = source[propertyName];
var oldValue = target[propertyName];
if (oldValue != newValue) {
target[propertyName] = newValue;
}
} else if (targetAttributeDetector(attributeName)) {
//setting property to '' seems to be the only cross-browser method for removing an attribute
target[propertyName] = '';
}
}
From my testing, I don't see either the sourceAttributeDetector() or targetAttributeDetector() conditions being satisfied which would mean the attribute never gets updated. This aligns with the fact that the response coming back from the server is correct in that the value has been cleared.
Since this code is similar to the code we passed to the Mojarra team for inclusion in JSF for 2.1.15, we should make sure we don't have the same problem there.
Before getting into the issue we have with the patched Mojarra it should be noted that the test case needs to be modified first. The TestBean.clear method invoked when the "Clear" button is clicked doesn't really clear the bound values rendered by the input text components present in the page. The test page should be modified to use the TestBean.altClear method instead.
Show
Mircea Toma
added a comment - - edited Before getting into the issue we have with the patched Mojarra it should be noted that the test case needs to be modified first. The TestBean.clear method invoked when the "Clear" button is clicked doesn't really clear the bound values rendered by the input text components present in the page. The test page should be modified to use the TestBean.altClear method instead.
Attached the patched Mojarra 2.1.3 patch. The patch is based on the latest patch submitted under http://java.net/jira/browse/JAVASERVERFACES-2461 case.
Show
Mircea Toma
added a comment - - edited Attached the patched Mojarra 2.1.3 patch. The patch is based on the latest patch submitted under http://java.net/jira/browse/JAVASERVERFACES-2461 case.
Attaching modified Mojarra 2.1.3 with both patches attached (jsf.js and UIComponentBase)
Show
Deryk Sinotte
added a comment - - edited Attaching modified Mojarra 2.1.3 with both patches attached (jsf.js and UIComponentBase)
Assignee: Mircea Toma (was: Ken Fyten)
Re-opened and assigned to Mircea.
Show
Deryk Sinotte
added a comment - - edited Assignee: Mircea Toma (was: Ken Fyten)
Re-opened and assigned to Mircea.
| Field | Original Value | New Value |
|---|---|---|
| Reporter | Migration [ remote ] | Arran Mccullough [ arran.mccullough ] |
| Assignee | Deryk Sinotte [ deryk.sinotte ] | |
| Fix Version/s | 3.3 [ 10370 ] | |
| Assignee Priority | P1 [ 10010 ] |
| Assignee | Deryk Sinotte [ deryk.sinotte ] | Mircea Toma [ mircea.toma ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
| Attachment | Case11742Example.war [ 14988 ] |
| Attachment | ICE-8731.patch [ 14993 ] |
| Attachment | javax.faces.jar [ 14995 ] |
| Status | Reopened [ 4 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Another observation, if I set the value bound objects to null directly instead of the clear code, it still doesn't work with the patched jar. It does however work with the non-patched jar.