Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 178421 Chrome Frame on M25 truncates approx. 2K of data from large pages at around byte 8220
Starred by 40 users Project Member Reported by robertshield@chromium.org, Feb 26 2013 Back to list
Status: Fixed
Owner:
Closed: Feb 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 0
Type: Bug



Sign in to add a comment
Version: 25.0.1364.97

Repro:

Visit any large page, e.g. www.yahoo.com in IE with CF immediately after opening IE.
Observe that parts of the page content are truncated.


 
Comment 1 by grt@chromium.org, Feb 26 2013
This appears to be caused by the fix for  issue 168308  (http://crrev.com/179932). Reverting that change makes this issue go away.
Comment 2 by ananta@chromium.org, Feb 26 2013
Cc: robertshield@chromium.org
Owner: ananta@chromium.org
Project Member Comment 3 by bugdroid1@chromium.org, Feb 26 2013
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=184718

------------------------------------------------------------------------
r184718 | ananta@chromium.org | 2013-02-26T20:26:43.421636Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/protocol_sink_wrap.cc?r1=184718&r2=184717&pathrev=184718

ChromeFrame sites in IE would appear truncated at times.

This was a regression caused by the change to invalidate the cached protocol data when IE (urlmon)
terminates the protocol. While this works well for non CF requests, for CF requests when we report
the changed mime type to be that of chrome, the protocol is terminated with cached data. When Chrome
attempts to read it we don't have anything to report which leads to the problem.

Fix is to not invalidate the protocol data for Chrome requests in our Terminate hook. We should invalidate
it for Abort because that seems like an error condition.

BUG= 178421 
R=robertshield.
Review URL: https://chromiumcodereview.appspot.com/12310145
------------------------------------------------------------------------
Labels: Merge-Requested
Comment 5 by laforge@google.com, Feb 26 2013
Labels: Mstone-25 Mstone-26
Comment 6 by k...@google.com, Feb 26 2013
Labels: -Merge-Requested Merge-Approved
Project Member Comment 7 by bugdroid1@chromium.org, Feb 26 2013
Labels: -Merge-Approved merge-merged-1364
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=184747

------------------------------------------------------------------------
r184747 | ananta@chromium.org | 2013-02-26T22:03:20.856244Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1364/src/chrome_frame/protocol_sink_wrap.cc?r1=184747&r2=184746&pathrev=184747

Merge 184718 - ChromeFrame sites in IE would appear truncated at times.

This was a regression caused by the change to invalidate the cached protocol data when IE (urlmon)
terminates the protocol. While this works well for non CF requests, for CF requests when we report
the changed mime type to be that of chrome, the protocol is terminated with cached data. When Chrome
attempts to read it we don't have anything to report which leads to the problem.

Fix is to not invalidate the protocol data for Chrome requests in our Terminate hook. We should invalidate
it for Abort because that seems like an error condition.

BUG= 178421 
R=robertshield.
Review URL: https://chromiumcodereview.appspot.com/12310145

TBR=ananta@chromium.org
Review URL: https://chromiumcodereview.appspot.com/12314131
------------------------------------------------------------------------
Comment 8 by ananta@chromium.org, Feb 26 2013
Labels: Merge-Requested
Need merge approval for M26
Comment 9 by tanyarad@google.com, Feb 26 2013
Sure, please validate on the latest M26 canary and I will approve.
Cc: karen@chromium.org cyrusm@chromium.org apps-tses-bugs@chromium.org
 Issue 178530  has been merged into this issue.
Cc: sentaro@chromium.org
 Issue 178530  has been merged into this issue.
Comment 12 by dharani@google.com, Feb 27 2013
Labels: -Merge-Requested Merge-Approved
Merge approved for M26.
Comment 13 by grt@chromium.org, Feb 27 2013
 Issue 178723  has been merged into this issue.
Project Member Comment 14 by bugdroid1@chromium.org, Feb 27 2013
Labels: -Merge-Approved merge-merged-1410
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=184998

------------------------------------------------------------------------
r184998 | ananta@chromium.org | 2013-02-27T19:01:19.965130Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/chrome_frame/protocol_sink_wrap.cc?r1=184998&r2=184997&pathrev=184998

Merge 184718
> ChromeFrame sites in IE would appear truncated at times.
> 
> This was a regression caused by the change to invalidate the cached protocol data when IE (urlmon)
> terminates the protocol. While this works well for non CF requests, for CF requests when we report
> the changed mime type to be that of chrome, the protocol is terminated with cached data. When Chrome
> attempts to read it we don't have anything to report which leads to the problem.
> 
> Fix is to not invalidate the protocol data for Chrome requests in our Terminate hook. We should invalidate
> it for Abort because that seems like an error condition.
> 
> BUG= 178421 
> R=robertshield.
> Review URL: https://chromiumcodereview.appspot.com/12310145

TBR=ananta@chromium.org
Review URL: https://codereview.chromium.org/12317154
------------------------------------------------------------------------
Status: Fixed
moving to fixed status.
 Issue 178832  has been merged into this issue.
Comment 17 by dunba...@gmail.com, Feb 28 2013
So, is there a size limit below which this problem does not occur?  Also, is it only the initial page request or subsequent requests as well?  I'd like to work around this but haven't been able to as of yet.
Dunbar, we found the first rendering works, but next ones don't. However pressing F5 then will show them correctly.(except in one customer who uses terminal services.

Chromium
Any ETA on when this fix will be pushed out ? 
Comment 19 by dunba...@gmail.com, Feb 28 2013
Thanks TaumataKid!  Hopefully I can find a work around for the immediate future.
Comment 20 by grt@chromium.org, Feb 28 2013
 Issue 178950  has been merged into this issue.
 Issue 178392  has been merged into this issue.
Project Member Comment 22 by bugdroid1@chromium.org, Feb 28 2013
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=185260

------------------------------------------------------------------------
r185260 | robertshield@chromium.org | 2013-02-28T16:32:31.694151Z

Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/test/data/chrome_frame_large_page.html?r1=185260&r2=185259&pathrev=185260
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/test/chrome_frame_test_utils.cc?r1=185260&r2=185259&pathrev=185260
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/test/test_with_web_server.cc?r1=185260&r2=185259&pathrev=185260

Add Chrome Frame test for large page rendering. This is designed to ensure that large pages load correctly in their entirety which should help catch bugs like  crbug.com/178421 .

Also fix access violation in code used by tests to shut down IE. 

BUG= 178421 
TEST=chrome_frame_tests.exe


Review URL: https://chromiumcodereview.appspot.com/12310162
------------------------------------------------------------------------
 Issue 178842  has been merged into this issue.
Comment 24 by grt@chromium.org, Feb 28 2013
 Issue 177813  has been merged into this issue.
Comment 25 by grt@chromium.org, Feb 28 2013
Cc: vikasmarwaha@chromium.org braveyao@chromium.org tnakamura@chromium.org
 Issue 177670  has been merged into this issue.
Comment 26 by Deleted ...@, Feb 28 2013
When can we expect a build for this issue?
Thanks
Raj
We just tried their beta version 26.0.1410.19 and it seems to work.  
Comment 28 by j...@erad.com, Mar 1 2013
(accidentally posted this on one of the closed duplicates before)
we're also experiencing the issue, even with 26.0.1410.19 beta.
we're having the problems with our own web app, server's set up to serve only specific pages to gcf (the others to be shown by ie)
the issue is intermittent however, but at one (of it's many) occurrences we were able to pinpoint the location of the corruption: one of the page sources (rendered jsp) was missing a chunk exactly from 0x2000 to 0x2800.
version info:
Google Chrome	26.0.1410.19 (Official Build 185128) beta-m
OS	Windows 
WebKit	537.31 (@144239)
JavaScript	V8 3.16.14.2
Flash	11.6.602.171
User Agent	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.19 Safari/537.31
Comment 29 by Deleted ...@, Mar 1 2013
We are also experiencing this issue. I think I will check here first next time instead of refactoring a bunch of code ; P.

Looking forward to this fix being pushed out soon.
Comment 30 by Deleted ...@, Mar 1 2013
Can you guys please tell us when this is going to be released officially? Customers are screaming at us :(.....

Thanks
Raj
We have the same problem in IE 9 and IE 10. Also, deleting browser cookies fixes the the problem for awhile but eventually it will reappear.
Comment 32 by Deleted ...@, Mar 4 2013
Any update?

Thanks
Raj
The fix to this will be pushed Very Soon now, unfortunately I can't provide the exact timing.
Project Member Comment 34 by bugdroid1@chromium.org, Mar 4 2013
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=185915

------------------------------------------------------------------------
r185915 | robertshield@chromium.org | 2013-03-04T17:37:57.318271Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1364/src/chrome_frame/protocol_sink_wrap.cc?r1=185915&r2=185914&pathrev=185915

Revert 184747
> Merge 184718 - ChromeFrame sites in IE would appear truncated at times.
> 
> This was a regression caused by the change to invalidate the cached protocol data when IE (urlmon)
> terminates the protocol. While this works well for non CF requests, for CF requests when we report
> the changed mime type to be that of chrome, the protocol is terminated with cached data. When Chrome
> attempts to read it we don't have anything to report which leads to the problem.
> 
> Fix is to not invalidate the protocol data for Chrome requests in our Terminate hook. We should invalidate
> it for Abort because that seems like an error condition.
> 
> BUG= 178421 
> R=robertshield.
> Review URL: https://chromiumcodereview.appspot.com/12310145
> 
> TBR=ananta@chromium.org
> Review URL: https://chromiumcodereview.appspot.com/12314131

TBR=ananta@chromium.org
Review URL: https://codereview.chromium.org/12391064
------------------------------------------------------------------------
Project Member Comment 35 by bugdroid1@chromium.org, Mar 4 2013
Labels: merge-merged-1364_152
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=185958

------------------------------------------------------------------------
r185958 | kerz@chromium.org | 2013-03-04T20:20:19.189186Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1364_152/src/chrome_frame/protocol_sink_wrap.cc?r1=185958&r2=185957&pathrev=185958

Revert 184747
> Merge 184718 - ChromeFrame sites in IE would appear truncated at times.
> 
> This was a regression caused by the change to invalidate the cached protocol data when IE (urlmon)
> terminates the protocol. While this works well for non CF requests, for CF requests when we report
> the changed mime type to be that of chrome, the protocol is terminated with cached data. When Chrome
> attempts to read it we don't have anything to report which leads to the problem.
> 
> Fix is to not invalidate the protocol data for Chrome requests in our Terminate hook. We should invalidate
> it for Abort because that seems like an error condition.
> 
> BUG= 178421 
> R=robertshield.
> Review URL: https://chromiumcodereview.appspot.com/12310145
> 
> TBR=ananta@chromium.org
> Review URL: https://chromiumcodereview.appspot.com/12314131

TBR=gman@chromium.org
Review URL: https://codereview.chromium.org/12377088
------------------------------------------------------------------------
Comment 36 by grt@chromium.org, Mar 5 2013
 Issue 180121  has been merged into this issue.
Very frustrated.  Had to make a big push with management to use Chrome Frame, and between the recently fixed new window bug and this one it's got a HUGE black eye now.  If chrome frame is not going to go through good QA we are going to have to abandon it.
The issue seems to have gone away for my colleague because newer version (25.0.1364.152) of Chrome Frame was pushed to his machine. For my machine, I didn't retrieve any new version yet. It still says 25.0.1364.97 (old version). How do I retrieve the latest update without re-installing Chrome Frame?
Comment 39 Deleted
Our customers are still experiencing crashes, our application will not even load due to this problem.  The previous post says it appears to be working in version 25.0.1364.152 but its still broken in that version as well as the latest beta version 26.0.1410.19.

The frustrating part is that our customers are not even running our application within a ChromeFrame.  Our application is crashing merely because their IT group installed the ChromeFrame addon in IE9 for an unrelated application.

Our application uses chunked transfer-encoding, so all data after 8,192 bytes are truncated (0x2000 bytes) causing our application to crash while it is loading.
@ddsnelle: If possible, could you contact me with a way of testing your application or a simple repro case?

The bug being tracked here caused data truncation only for pages rendered by CF. If your app is not rendered by CF, I'm curious as to whether what you're seeing is related to this bug or is something different.
Comment 42 Deleted
Comment 43 by j...@erad.com, Mar 7 2013
we've been seeing this with version (as per my comment #28):
26.0.1410.19 (Official Build 185128) beta-m
which version, if any (on any of the channels) has the fix candidate?

Beta channel >= 26.0.1410.28 should have the fix.
Stable channel >= 25.0.1364.152 should also not show this problem. 

Everyone on beta should be upgraded to .28 now or very soon now. The stable channel rollout is happening slightly more slowly, but for those who need a fix right away reinstalling CF will get the latest stable channel version.

If anyone continues to encounter the truncation issue on either of those versions, please reply to this bug.
Comment 45 by Deleted ...@, Mar 7 2013
Thank you Robert! I'm happy to see this resolved relatively quickly. Could you please provide an estimate for the stable channel rollout? I need to provide an update to management and "slightly more slowly" is slightly ambiguous. 

If it will be pushed out in the next couple of days, I won't bother. If it is going to be another week or so, I may instruct the network services department to delete/reinstall GCF on all company PCs.

Again, thank you for your work resolving this bug and keeping us all updated.
I updated from version .97 to version .152 today.  It appears to have fixed our issue where content from our long header element was being truncated.  I will continue to test and let you know if an issue arises.  Once interesting observation, when I am on cnn.com and type yahoo.com ( GCF site ), it changes yahoo.com back to cnn.com then navigates to yahoo.com.  It does not see to add any delay or cause an issue, but it is something new I didn't notice before.
Thank you very much for a speedy turnaround on this issue.  I have tested 26.0.1410.28 and our problem with chunked transfer-encoding is no longer an issue.  I look forward to seeing this rolled out in the stable channel.

For clarity and for future record, I am clarifying my previous post.  The problem we saw was that the byte count at the beginning of each new chunk in the response data was being read by the ChromeFrame Addon as part of the data rather than as the number of bytes in the next chunk of data rendering invalid XML.

Thank you again for the speedy fix.
I uninstalled the Beta and installed the Stable Channel and it is working as expected in 25.0.1364.160.  Thank you again.
Project Member Comment 49 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Feature-ChromeFrame -Mstone-25 -Mstone-26 Cr-Internals Cr-ChromeFrame M-25 M-26
Sign in to add a comment