ICEfaces
  1. ICEfaces
  2. ICE-10980

JSF h:selectOneListbox, h:selectOneMenu components not escaping HTML text in labels

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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:
    • 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

      With the standard JSF components (h:selectOneListbox, h:selectOneMenu), the backing select item list is not escaping html characters. The same is escaped correctly when using the ice:selectOneListbox/selectOneMenu.

      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"

        Activity

        Arran Mccullough created issue -
        Hide
        Arran Mccullough added a comment -

        Attached test case that shows this issue.

        Steps:

        • Load welcomeICEfaces.jsf to see the issue. The first components are the standard JSF components.
        Show
        Arran Mccullough added a comment - Attached test case that shows this issue. Steps: Load welcomeICEfaces.jsf to see the issue. The first components are the standard JSF components.
        Arran Mccullough made changes -
        Field Original Value New Value
        Attachment Case13718Example.war [ 22103 ]
        Attachment Case13718Example.zip [ 22104 ]
        Ken Fyten made changes -
        Assignee Arturo Zambrano [ artzambrano ]
        Fix Version/s EE-3.3.0.GA_P05 [ 13082 ]
        Fix Version/s 4.3 [ 13096 ]
        Assignee Priority P2 [ 10011 ]
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Ken Fyten made changes -
        Summary JSF Select menu/list not escaping HTML text in labels JSF h:selectOneListbox, h:selectOneMenu components not escaping HTML text in labels
        Ken Fyten made changes -
        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.
        Workaround Exists Yes [ 10007 ]
        Hide
        Ken Fyten added a comment -

        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".

        Show
        Ken Fyten added a comment - 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".
        Ken Fyten made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Won't Fix [ 2 ]

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: