MyFaces Core
  1. MyFaces Core
  2. MYFACES-3321

jsf.js: Script fragments evaluated after an ajax operation encode '&' character into '&'

    Details

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

      Description

      Script fragments containing & characters are encoded into & before the script is evaluated. I checked the code from the server side and it is correct, so the problem is on the javascript part.

        Activity

        Leonardo Uribe created issue -
        Hide
        Werner Punz added a comment -

        I will investigate this issue sometime next week

        Show
        Werner Punz added a comment - I will investigate this issue sometime next week
        Werner Punz made changes -
        Field Original Value New Value
        Summary Script fragments evaluated after an ajax operation encode '&' character into '&' jsf.js: Script fragments evaluated after an ajax operation encode '&' character into '&'
        Werner Punz made changes -
        Assignee Werner Punz [ werpu ]
        Werner Punz made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Werner Punz added a comment - - edited

        This is not a bug. The only time this happens in my testcases here is whenever a innerHTML is issued from the script itself with an & sign. And there the browser simply has this behavior. Normal & are not affected.
        aka
        <script>
        node.innerHTML = "bla & bla" results in bla & bla due to browser behavior regarding innerHTML
        </script>
        <script>
        true && true;
        </script>
        will show up in the browser as final result true && true

        Show
        Werner Punz added a comment - - edited This is not a bug. The only time this happens in my testcases here is whenever a innerHTML is issued from the script itself with an & sign. And there the browser simply has this behavior. Normal & are not affected. aka <script> node.innerHTML = "bla & bla" results in bla & bla due to browser behavior regarding innerHTML </script> <script> true && true; </script> will show up in the browser as final result true && true
        Hide
        Werner Punz added a comment -

        Ok the example Leo gave me triggering this issue causes an internal error in the javascripts exposing itself as error message in jsf.js. I have yet to debug into this error, but I assume it is the mentioned problem of a script eval failing.

        Show
        Werner Punz added a comment - Ok the example Leo gave me triggering this issue causes an internal error in the javascripts exposing itself as error message in jsf.js. I have yet to debug into this error, but I assume it is the mentioned problem of a script eval failing.
        Hide
        Werner Punz added a comment -

        Another thing I noticed, jsf.js is reloaded, this should not happen according to the code.
        I will investigate into that as well.

        Show
        Werner Punz added a comment - Another thing I noticed, jsf.js is reloaded, this should not happen according to the code. I will investigate into that as well.
        Hide
        Werner Punz added a comment -

        The double import was caused by a check for jsf.js which did only executed half the code it should, I now have changed the code accordingly, so that it imports jsf.js only if it is not present in the window namespace (which is basically never unless someone causes such a condition manually)

        Show
        Werner Punz added a comment - The double import was caused by a check for jsf.js which did only executed half the code it should, I now have changed the code accordingly, so that it imports jsf.js only if it is not present in the window namespace (which is basically never unless someone causes such a condition manually)
        Hide
        Werner Punz added a comment -

        Ok the root cause of this problem, and it only can happen in the head replacement code is following.
        a) Browsers do not allow a direct head replacement.

        b) Instead the head is more or less generated and then parsed by an xml construct (and if not a direct head replacement is tried). The xml construct parses the code as xml and during this parsing step a deserialize xml is called to get the script text data. This works but it encodes & into amp, now, we do not need that for script tags in most cases, a simple xml.text should suffice which does not encode the &. So I will add the xml.text as fallback if present, this should resolve the issue.

        The normal update cases are not touched by this issue, hence it has not crawled up so far.

        Show
        Werner Punz added a comment - Ok the root cause of this problem, and it only can happen in the head replacement code is following. a) Browsers do not allow a direct head replacement. b) Instead the head is more or less generated and then parsed by an xml construct (and if not a direct head replacement is tried). The xml construct parses the code as xml and during this parsing step a deserialize xml is called to get the script text data. This works but it encodes & into amp, now, we do not need that for script tags in most cases, a simple xml.text should suffice which does not encode the &. So I will add the xml.text as fallback if present, this should resolve the issue. The normal update cases are not touched by this issue, hence it has not crawled up so far.
        Werner Punz made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 2.0.10-SNAPSHOT [ 12317869 ]
        Fix Version/s 2.1.4-SNAPSHOT [ 12317867 ]
        Resolution Fixed [ 1 ]
        Hide
        Werner Punz added a comment -

        The bugfix opened another bug. Now deeper elements in replace body and head are ignored entirely. We have to work differently here.

        Show
        Werner Punz added a comment - The bugfix opened another bug. Now deeper elements in replace body and head are ignored entirely. We have to work differently here.
        Werner Punz made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Werner Punz added a comment -

        The issue is that the new serialisation code produces wrong results for non javascript elements.
        I personally think the only viable option simply is to revert to a parsing for the body and a full innerHTML.
        Everything else does not work out.

        Show
        Werner Punz added a comment - The issue is that the new serialisation code produces wrong results for non javascript elements. I personally think the only viable option simply is to revert to a parsing for the body and a full innerHTML. Everything else does not work out.
        Hide
        Werner Punz added a comment -

        i now have switched to the parsing code for the content and only revert to the xml code for the attributes parsing

        Show
        Werner Punz added a comment - i now have switched to the parsing code for the content and only revert to the xml code for the attributes parsing
        Werner Punz made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Leonardo Uribe made changes -
        Fix Version/s 2.0.10 [ 12317870 ]
        Fix Version/s 2.1.4 [ 12317868 ]
        Fix Version/s 2.1.4-SNAPSHOT [ 12317867 ]
        Fix Version/s 2.0.10-SNAPSHOT [ 12317869 ]
        Leonardo Uribe made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development