MyFaces Core
  1. MyFaces Core
  2. MYFACES-3339

Ajax embedded CDATA Sequence lost on the server once an ajax refresh is triggered

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.10-SNAPSHOT, 2.1.4-SNAPSHOT
    • Fix Version/s: 2.0.10, 2.1.4
    • Component/s: None
    • Labels:
      None

      Description

      One of my automated tests regarding render javax.faces.ViewRoot fails on chrome and ie, it works on all other browsers.

        Activity

        Hide
        Leonardo Uribe added a comment -

        The problem is on PartialResponseWriterImpl. There is a line that removes all cdata sections, which is obviously wrong. So just removing that line is enough. I test it doing a full ajax refresh with the example on MYFACES-2801 and it works. So the code to handle cdata on HtmlResponseWriterImpl is ok. Probably that line was added because we had the problem described on MYFACES-2801

        Show
        Leonardo Uribe added a comment - The problem is on PartialResponseWriterImpl. There is a line that removes all cdata sections, which is obviously wrong. So just removing that line is enough. I test it doing a full ajax refresh with the example on MYFACES-2801 and it works. So the code to handle cdata on HtmlResponseWriterImpl is ok. Probably that line was added because we had the problem described on MYFACES-2801
        Hide
        Werner Punz added a comment - - edited

        Ok a client side fix does not make sense there. This needs to be resolved on partial response writer level.
        The myfaces ppr should introduce CDATA escapes aka the script should become:

        <script type="text/javascript">
        // <CDATA[[
        var a && b;
        // ]]>
        </script>

        <update id="..."><CDATA[[...
        <script="text/javascript">
        // <!CDATA[[
        // ]]]]><!CDATA[[>
        </script>
        ]]></update>

        This is perfectly viable since more than one cdata section can follow the update.

        The CDATA Escaping code still is present in the partial response writer, so I assume the comment with the CDATA section must be lost earlier.

        Show
        Werner Punz added a comment - - edited Ok a client side fix does not make sense there. This needs to be resolved on partial response writer level. The myfaces ppr should introduce CDATA escapes aka the script should become: <script type="text/javascript"> // <CDATA[[ var a && b; // ]]> </script> <update id="..."><CDATA[[... <script="text/javascript"> // <!CDATA[[ // ]]]]><!CDATA[[> </script> ]]></update> This is perfectly viable since more than one cdata section can follow the update. The CDATA Escaping code still is present in the partial response writer, so I assume the comment with the CDATA section must be lost earlier.
        Hide
        Werner Punz added a comment -

        Ok the reason simply is I have following case:
        <head>
        <script type="text/javascript">
        <![CDATA[
        var a && b;
        ]]>
        </script>

        And then the server returns at the ajax refresh
        <script type="text/javascript">
        var a && b;
        </script>

        Now thanks to the xml parsing performed at the head and body replacement stage. The parser rightfully complains that this is not a valid xhml due to the && in the code.
        I will try to add a fix on the client side but the final fix must come from the server if possible.

        Show
        Werner Punz added a comment - Ok the reason simply is I have following case: <head> <script type="text/javascript"> <![CDATA[ var a && b; ]]> </script> And then the server returns at the ajax refresh <script type="text/javascript"> var a && b; </script> Now thanks to the xml parsing performed at the head and body replacement stage. The parser rightfully complains that this is not a valid xhml due to the && in the code. I will try to add a fix on the client side but the final fix must come from the server if possible.

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Werner Punz
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development