myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] [Commented] (MYFACES-3835) ViewState gets truncated on chrome with richfaces fileupload component
Date Wed, 18 Dec 2013 17:16:08 GMT


Leonardo Uribe commented on MYFACES-3835:

Just for the record, It seems a bug on webkit

There is no relationship with any param of MyFaces. There is similar report to this one here:

Maybe we need a workaround on the javascript part to deal with this chrome bug.

> ViewState gets truncated on chrome with richfaces fileupload component
> ----------------------------------------------------------------------
>                 Key: MYFACES-3835
>                 URL:
>             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
>         Attachments: FileUploadBean.class,, imgUpload-sample.xhtml,
> 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
> 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
> 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

View raw message