[
https://issues.apache.org/jira/browse/MYFACES-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-3835.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.2.0-beta
2.1.14-SNAPSHOT
2.0.20-SNAPSHOT
> 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.11, 2.1.13
> 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
> Fix For: 2.0.20-SNAPSHOT, 2.1.14-SNAPSHOT, 2.2.0-beta
>
> Attachments: FileUploadBean.class, FileUploadBean.java,
> imgUpload-sample.xhtml, web.xml
>
>
> 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)