You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Ricardo Tercero Lozano (JIRA)" <de...@myfaces.apache.org> on 2013/12/18 16:09:06 UTC

[jira] [Created] (MYFACES-3835) ViewState gets truncated on chrome with richfaces fileupload component

Ricardo Tercero Lozano created MYFACES-3835:
-----------------------------------------------

             Summary: ViewState gets truncated on chrome with richfaces fileupload component
                 Key: MYFACES-3835
                 URL: https://issues.apache.org/jira/browse/MYFACES-3835
             Project: MyFaces Core
          Issue Type: Bug
    Affects Versions: 2.1.13, 2.1.11
         Environment: Windows XP, Chrome 31.0.1650.63 m (latest at this moment), tomcat 7.0.37, client state saving, myfaces 2.1.11, richfaces 4.3.1.Final
            Reporter: Ricardo Tercero Lozano


On certain conditions viewstate gets corrupted (truncated).

I've got a page with a richfaces fileupload component. The page works well on IE7 and Firefox (latest), but not in chrome. Digging into Javascript and Ajax response I got some extra info about the problem. I don't know why, but a partial response like:

<?xml version="1.0" encoding="utf-8"?><partial-response><changes><update id="javax.faces.ViewState"><![CDATA[....

results in two CDATA sections when handling the response. This is the problem caused by Google Chrome. Inspecting the JSF.JS library, the line that gets de updated view state is:

mfInternal.appliedViewState = node.firstChild.nodeValue;

This line is in 'processUpdate' method. When Chrome, for some reason splits the original CDATA block into two, that line only updates the first section, obtaining a truncated viewState and ViewExpiredException in next request.

The first CDATA section created by Google Chrome has 300 bytes. Weird, but searching Google for 'Chrome cdata 300' appears to be a libxml2 problem.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)