[DevTools] Always report encodedDataLength in Network.ResponseReceived.

[DevTools] Always report encodedDataLength in Network.ResponseReceived.

Currently, we only send encodedDataLength for redirects. However, we already know how much we read when sending ResponseReceived. This will improve reporting for failed requests, as they don't get loadingFinished with full encodedDataLength.

BUG=622018
Committed: https://crrev.com/00f8f6c17d27799700974e599d6003b7f376071c
Cr-Commit-Position: refs/heads/master@{#402543}

[dgozman, 2016-06-27 23:00:47]

Description was changed from

==========
[DevTools] Always report encodedDataLength in Network.ResponseReceived.

BUG=622018
==========

to

==========
[DevTools] Always report encodedDataLength in Network.ResponseReceived.

Currently, we only send encodedDataLength for redirects. However, we already
know how much we read when sending ResponseReceived. This will improve reporting
for failed requests, as they don't get loadingFinished with full
encodedDataLength.

BUG=622018
==========

[dgozman, 2016-06-27 23:02:43]

dgozman@chromium.org changed reviewers:
+ allada@chromium.org, mmenke@chromium.org

[dgozman, 2016-06-27 23:02:43]

Could you please take a look?

https://codereview.chromium.org/2101073002/diff/1/content/browser/loader/netl...
File content/browser/loader/netlog_observer.cc (right):

https://codereview.chromium.org/2101073002/diff/1/content/browser/loader/netl...
content/browser/loader/netlog_observer.cc:198:
response->head.encoded_data_length = request->GetTotalReceivedBytes();
This field is only used by DevTools, so it should probably go into
ResourceDevToolsInfo. But that's a separate follow-up.

[mmenke, 2016-06-28 13:42:58]

https://codereview.chromium.org/2101073002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/http/tests/inspector/network/network-datareceived.html
(right):

https://codereview.chromium.org/2101073002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/http/tests/inspector/network/network-datareceived.html:22:
function responseReceived(requestId, frameId, loaderId, time, resourceType,
response)
Where to these new parameters come from?

[dgozman, 2016-06-28 14:03:08]

https://codereview.chromium.org/2101073002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/http/tests/inspector/network/network-datareceived.html
(right):

https://codereview.chromium.org/2101073002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/http/tests/inspector/network/network-datareceived.html:22:
function responseReceived(requestId, frameId, loaderId, time, resourceType,
response)
On 2016/06/28 13:42:58, mmenke wrote:
> Where to these new parameters come from?

Looks like the test was not updated when protocol event got new parameters.
Since it's javascript, and we only used requestId inside the function, things
worked. Now I need response, so I've updated.

[mmenke, 2016-06-28 14:04:04]

On 2016/06/28 14:03:08, dgozman wrote:
>
https://codereview.chromium.org/2101073002/diff/1/third_party/WebKit/LayoutTe...
> File
>
third_party/WebKit/LayoutTests/http/tests/inspector/network/network-datareceived.html
> (right):
> 
>
https://codereview.chromium.org/2101073002/diff/1/third_party/WebKit/LayoutTe...
>
third_party/WebKit/LayoutTests/http/tests/inspector/network/network-datareceived.html:22:
> function responseReceived(requestId, frameId, loaderId, time, resourceType,
> response)
> On 2016/06/28 13:42:58, mmenke wrote:
> > Where to these new parameters come from?
> 
> Looks like the test was not updated when protocol event got new parameters.
> Since it's javascript, and we only used requestId inside the function, things
> worked. Now I need response, so I've updated.

ok, LGTM.

[allada, 2016-06-28 19:18:34]

lgtm

lgtm

[dgozman, 2016-06-28 19:21:44]

The CQ bit was checked by dgozman@chromium.org

[commit-bot: I haz the power, 2016-06-28 19:23:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-28 21:16:26]

Description was changed from

==========
[DevTools] Always report encodedDataLength in Network.ResponseReceived.

Currently, we only send encodedDataLength for redirects. However, we already
know how much we read when sending ResponseReceived. This will improve reporting
for failed requests, as they don't get loadingFinished with full
encodedDataLength.

BUG=622018
==========

to

==========
[DevTools] Always report encodedDataLength in Network.ResponseReceived.

Currently, we only send encodedDataLength for redirects. However, we already
know how much we read when sending ResponseReceived. This will improve reporting
for failed requests, as they don't get loadingFinished with full
encodedDataLength.

BUG=622018
==========

[commit-bot: I haz the power, 2016-06-28 21:16:27]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-28 21:20:21]

Description was changed from

==========
[DevTools] Always report encodedDataLength in Network.ResponseReceived.

Currently, we only send encodedDataLength for redirects. However, we already
know how much we read when sending ResponseReceived. This will improve reporting
for failed requests, as they don't get loadingFinished with full
encodedDataLength.

BUG=622018
==========

to

==========
[DevTools] Always report encodedDataLength in Network.ResponseReceived.

Currently, we only send encodedDataLength for redirects. However, we already
know how much we read when sending ResponseReceived. This will improve reporting
for failed requests, as they don't get loadingFinished with full
encodedDataLength.

BUG=622018

Committed: https://crrev.com/00f8f6c17d27799700974e599d6003b7f376071c
Cr-Commit-Position: refs/heads/master@{#402543}
==========

[commit-bot: I haz the power, 2016-06-28 21:20:22]

Patchset 1 (id:??) landed as
https://crrev.com/00f8f6c17d27799700974e599d6003b7f376071c
Cr-Commit-Position: refs/heads/master@{#402543}

[dgozman, 2016-07-18 17:58:02]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/2158073002/ by dgozman@chromium.org.

The reason for reverting is: Decided to try another approach, see discussion in
issue 622018.