New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 799811 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Transfer size equals to content size only happens on first item in network panel of DevTools

Reported by ro...@iworm.net, Jan 8 2018

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
1. Open DevTools and switch to network panel.
2. Click "Use large request rows" icon, so there will show "Transfer Size" and "Content Size" in "Size" column.
3. Open http://news.163.com or any other websites.
4. After all contents are loaded. Please look at the "size" column.
5. You will find the two size are equal, and this will only happens to the first item. All others has different "Transfer Size" and "Content Size".
6. Check the response of the first item, you will find the content encoding is set to gzip, so the two size should not be equal in most of cases.

What is the expected behavior?
"Size" column displays the correct transfer size.

What went wrong?
Only the first item in network panel displays the wrong transfer size.

Did this work before? N/A 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: Ubuntu 17.10
Flash Version:
 
Screenshot from 2018-01-08 09-51-22.png
74.3 KB View Download

Comment 1 by ro...@iworm.net, Jan 8 2018

I've found the same issue on latest Mac and Windows version of Chrome.
Cc: sc00335...@techmahindra.com
Components: -Platform>DevTools Platform>DevTools>Network
Labels: -Type-Bug -Pri-2 hasbisect-per-revision ReleaseBlock-Stable M-63 Needs-Triage-M63 OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: caseq@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 63.0.3239.132 with steps mentioned in comment#0. But not reproducible on beta 64.0.3282.71 and canary 65.0.3315.0 using Windows10, Ubuntu 14.04 and Mac 10.13.1. Hence providing reverse bisect info.

Last Bad Build: 64.0.3267.0
First Good Build: 64.0.3268.0

You are probably looking for a change made after 516011 (known good), but no later than 516012 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/98e533d332344ee7fdf2cace842c61b25b4a2020..81f89b3b8fbb90742d88ffef7d82a561cfee3c5b

Reviewed-on: https://chromium-review.googlesource.com/744290

Suspecting same from changelog.

@caseq: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-63. Please remove if not the case.

Thanks!




Comment 3 by gov...@chromium.org, Jan 16 2018

Cc: manoranj...@chromium.org abdulsyed@chromium.org
Labels: M-64
We're not planning any further M63 releases. 

Per comment #2, this is fixed in M64, correct?
Status: WontFix (was: Assigned)
roger@, Next M64 stable release will have this fix which is going to happen very soon. Please feel free to update the thread if you still see any issues after M64 stable release.

Thank you!

Sign in to add a comment