Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Won't Fix
-
Affects Version/s: EE-3.3.0.GA_P03, 4.1.1
-
Fix Version/s: EE-3.3.0.GA_P05, 4.3
-
Component/s: Framework
-
Labels:None
-
Environment:All
-
Assignee Priority:P2
-
Support Case References:Support Case #13718 - https://icesoft.my.salesforce.com/5007000001ZLfA9
-
Workaround Exists:Yes
-
Workaround Description:Workaround for this issue is to use the ice:selectOneListbox or ice:selectOneMenu components instead of the h: ones as they do not have this issue.
Description
It is also escaping correctly when using a pure JSF sample. When ICEfaces is added, it displays the label like it uses escape=false.
Sample code:
<h:selectOneListbox value="#{testBean.id1}" size="4">
<f:selectItems value="#{testBean.items}"/>
</h:selectOneListbox>
List items:
"hello"
"hello <world"
"8 > 3"
"9 = 9"
With ICEfaces shows list as:
"hello"
"hello "
"8 > 3"
"9 = 9"
Pure JSF and ICE comps show list as:
"hello"
"hello <world"
"8 > 3"
"9 = 9"
-
Hide
- Case13718Example.zip
- 21 kB
- Arran Mccullough
-
- Case13718Example/build.xml 3 kB
- Case13718Example/.../ant-deploy.xml 2 kB
- Case13718Example/.../build-impl.xml 80 kB
- Case13718Example/.../genfiles.properties 0.5 kB
- Case13718Example/.../private.properties 0.6 kB
- Case13718Example/nbproject/.../private.xml 0.3 kB
- Case13718Example/.../project.properties 4 kB
- Case13718Example/nbproject/project.xml 0.9 kB
- Case13718Example/src/conf/MANIFEST.MF 0.0 kB
- Case13718Example/src/.../support/Item.java 0.1 kB
- Case13718Example/src/.../TestBean.java 1 kB
- Case13718Example/web/index.xhtml 0.5 kB
- Case13718Example/web/.../context.xml 0.1 kB
- Case13718Example/web/WEB-INF/web.xml 2 kB
- Case13718Example/.../welcomeICEfaces.xhtml 1 kB
-
Hide
- Case13718Example.war
- 13.42 MB
- Arran Mccullough
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.1 kB
- WEB-INF/classes/com/.../support/Item.class 0.3 kB
- WEB-INF/classes/.../support/TestBean.class 2 kB
- WEB-INF/lib/commons-beanutils.jar 226 kB
- WEB-INF/lib/commons-digester.jar 140 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/icefaces-ace.jar 5.64 MB
- WEB-INF/lib/icefaces-compat.jar 4.18 MB
- WEB-INF/lib/icefaces.jar 642 kB
- WEB-INF/lib/javax.faces.jar 2.55 MB
- WEB-INF/web.xml 2 kB
- index.xhtml 0.5 kB
- welcomeICEfaces.xhtml 1 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
This is an issue in the core framework. An easy way to appreciate this issue is to run the application with no other jars but the mojarra jar and see that the less than and greater than symbols on the page are correctly escaped. Then, the application can be run again adding only icefaces.jar, and those same symbols won't be escaped correctly on the page. No other icefaces components need to be on the page.
It seems like all the <option> elements are passed as plan text to one of the write() methods in DOMResponseWriter. The following text is passed as the string argument of the write() method for these h:* components:
<option value="1.0" selected="true">hello</option> <option value="2.0">hello <world</option> <option value="3.0">8 > 3</option> <option value="4.0">9 = 9</option>
The less than and greater than symbols in the body are passed unescaped to this method. If we escaped that entire piece of text, we would also be escaping the tag delimiters, which wouldn't have the desired effect.
The only solution I have in mind is to add some code specifically for this case. If we detect a piece of text that starts with '<option' and ends with '</option>', we parse it, extracting the body of these tags (and the attribute values) and escaping them.
I don't know what calls this write() method in DOMResponseWriter and passes the rendered markup of standard h:* components. Perhaps the original text is escaped, but it's unescaped by us at some point. Detecting this could also fix the issue.
This issue can also be reproduced in the 4.0 trunk.
Due to the lack of a viable solution for this and the fact that the ice:selectOneMenu and ice:selectOneListbox components are readily available for use and do not suffer from this limitation, marking this as "Won't Fix".
Attached test case that shows this issue.
Steps: