Render process changes for ResourceTiming sizes.

Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-BQAJ

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8KduY/edit
for a far more detailed description of the changes.

BUG=467945
TBR=liberato

Committed: https://crrev.com/d91ea73de426248bf5d8524da38c07c0a6b34b19
Cr-Commit-Position: refs/heads/master@{#406527}

[Adam Rice, 2016-06-28 10:24:38]

ricea@chromium.org changed reviewers:
+ kinuko@chromium.org

[Adam Rice, 2016-06-28 10:24:39]

PTAL

[kinuko, 2016-06-28 15:35:08]

Hmm, subtle terminology diffs are very confusing :( I will need to take another
look but here're some initial comments.

Reg: tests-- I don't really feel having additional tests in
resource_dispatcher_unittest is too useful as it's basically just forwarding
values--  maybe having something with redirects in ResourceFetcherTest?

https://codereview.chromium.org/2105713002/diff/1/content/public/child/reques...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/2105713002/diff/1/content/public/child/reques...
content/public/child/request_peer.h:43: // |payload|, |length| and
|encoded_length| functions are thread-safe, but
please update this comment too

https://codereview.chromium.org/2105713002/diff/1/content/public/child/reques...
content/public/child/request_peer.h:57: virtual int encoded_body_length() const
= 0;
It'd be probably nicer to clearly explain how encoded_length and
encoded_body_length differ (rather than the diff from the data length)

(Also... if possible we might want to update 'encoded_length' field name to
encoded_data_length together now?)

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_url_loader_host.cc (right):

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
content/renderer/pepper/pepper_url_loader_host.cc:127: int64_t
encodedDataLength) {
encoded_data_length

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_url_loader_host.h (right):

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
content/renderer/pepper/pepper_url_loader_host.h:51: int64_t encodedDataLength)
override;
encoded_data_length

https://codereview.chromium.org/2105713002/diff/1/media/blink/buffered_resour...
File media/blink/buffered_resource_loader.h (right):

https://codereview.chromium.org/2105713002/diff/1/media/blink/buffered_resour...
media/blink/buffered_resource_loader.h:141: int64_t encodedDataLength) override;
style is inconsistent here and below but looks like it's an existing issue :(

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl
(right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl:51:
[RuntimeEnabled=ResourceTimingSizes] readonly attribute unsigned short
decodedBodySize;
We sent out I2S so basically we don't need to make this behind the flag, am I
right?

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/network/ResourceResponse.h (right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/network/ResourceResponse.h:380: long long
m_responseBodySize;
The length/size terminology inconsistency bothers me a bit... looks like
encodedDataLength is existing terminology that's being used in Blink, but where
this 'responseBodySize' comes from? (I did quick code search but wasn't able to
find much precedence)

It's sad that we use different terminology depending on layers, but could we
still try to minimize # of variations?  Maybe... use the same terminology as
ResourceTiming (or encodedBodyLength and decodedBodyLength) here?

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/web/AssociatedURLLoader.cpp (right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/web/AssociatedURLLoader.cpp:152: // FIXME: Set
encodedDataLength
Are you going to plumb this too?  Do we need to propagate values via
Resource::willFollowRedirect?

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/web/AssociatedURLLoader.cpp:212:
m_client->didReceiveData(m_loader, data, dataLength, -1, dataLength);
In this case we might be adding up -1 to the responseBodySize (==
decodedBodySize)?

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/public/p...
File third_party/WebKit/public/platform/WebURLLoaderClient.h (right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/public/p...
third_party/WebKit/public/platform/WebURLLoaderClient.h:49: WebURLLoader*,
WebURLRequest& newRequest, const WebURLResponse& redirectResponse, int64_t
encodedDataSize) {}
encodedDataLength?

[Yoav Weiss, 2016-06-29 06:59:38]

On 2016/06/28 10:24:39, Adam Rice wrote:
> PTAL

Any particular reason for the layout tests to be in a separate CL?

[Adam Rice, 2016-06-29 09:52:15]

I haven't added ResourceFetcher test(s) yet. I will do it tomorrow.

https://codereview.chromium.org/2105713002/diff/1/content/public/child/reques...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/2105713002/diff/1/content/public/child/reques...
content/public/child/request_peer.h:43: // |payload|, |length| and
|encoded_length| functions are thread-safe, but
On 2016/06/28 15:35:07, kinuko wrote:
> please update this comment too

Done.

https://codereview.chromium.org/2105713002/diff/1/content/public/child/reques...
content/public/child/request_peer.h:57: virtual int encoded_body_length() const
= 0;
On 2016/06/28 15:35:07, kinuko wrote:
> It'd be probably nicer to clearly explain how encoded_length and
> encoded_body_length differ (rather than the diff from the data length)
> 
> (Also... if possible we might want to update 'encoded_length' field name to
> encoded_data_length together now?)

I have tried to make the comments clearer. I also renamed encoded_length to
encoded_data_length for consistency.

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_url_loader_host.cc (right):

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
content/renderer/pepper/pepper_url_loader_host.cc:127: int64_t
encodedDataLength) {
On 2016/06/28 15:35:07, kinuko wrote:
> encoded_data_length

Done.

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_url_loader_host.h (right):

https://codereview.chromium.org/2105713002/diff/1/content/renderer/pepper/pep...
content/renderer/pepper/pepper_url_loader_host.h:51: int64_t encodedDataLength)
override;
On 2016/06/28 15:35:07, kinuko wrote:
> encoded_data_length

Fixed, thanks.

https://codereview.chromium.org/2105713002/diff/1/media/blink/buffered_resour...
File media/blink/buffered_resource_loader.h (right):

https://codereview.chromium.org/2105713002/diff/1/media/blink/buffered_resour...
media/blink/buffered_resource_loader.h:141: int64_t encodedDataLength) override;
On 2016/06/28 15:35:07, kinuko wrote:
> style is inconsistent here and below but looks like it's an existing issue :(

Acknowledged.

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl
(right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl:51:
[RuntimeEnabled=ResourceTimingSizes] readonly attribute unsigned short
decodedBodySize;
On 2016/06/28 15:35:07, kinuko wrote:
> We sent out I2S so basically we don't need to make this behind the flag, am I
> right?

I misunderstood that part of the launch process. I have removed the flag.

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/network/ResourceResponse.h (right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/network/ResourceResponse.h:380: long long
m_responseBodySize;
On 2016/06/28 15:35:07, kinuko wrote:
> The length/size terminology inconsistency bothers me a bit... looks like
> encodedDataLength is existing terminology that's being used in Blink, but
where
> this 'responseBodySize' comes from? (I did quick code search but wasn't able
to
> find much precedence)
> 
> It's sad that we use different terminology depending on layers, but could we
> still try to minimize # of variations?  Maybe... use the same terminology as
> ResourceTiming (or encodedBodyLength and decodedBodyLength) here?

I find it confusing that Response::decodedSize() exists and means something else
completely. I've chosen decodedBodyLength as it looks like the least-worst
alternative to me.

I've also updated the design doc to summarize the different names used at
different layers.

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/web/AssociatedURLLoader.cpp (right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/web/AssociatedURLLoader.cpp:152: // FIXME: Set
encodedDataLength
On 2016/06/28 15:35:08, kinuko wrote:
> Are you going to plumb this too?  Do we need to propagate values via
> Resource::willFollowRedirect?

I'm not sure whether it is actually needed. I haven't worked out what
AssociatedURLLoader is used for yet.

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/web/AssociatedURLLoader.cpp:212:
m_client->didReceiveData(m_loader, data, dataLength, -1, dataLength);
On 2016/06/28 15:35:08, kinuko wrote:
> In this case we might be adding up -1 to the responseBodySize (==
> decodedBodySize)?

It gets added to the encodedDataSize, but it is a problem. I tried putting a
CHECK in ResourceTimingInfo and running the layout tests and found many other
places where -1 is passed. Fortunately they don't seem to be common cases, so I
think it is acceptable for the purposes of this CL. I added a check in
ResourceFetcher to convert -1 to 0 before passing to ResourceTimingInfo and a
FIXME to chase down the cases where the value should be set but isn't.

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/public/p...
File third_party/WebKit/public/platform/WebURLLoaderClient.h (right):

https://codereview.chromium.org/2105713002/diff/1/third_party/WebKit/public/p...
third_party/WebKit/public/platform/WebURLLoaderClient.h:49: WebURLLoader*,
WebURLRequest& newRequest, const WebURLResponse& redirectResponse, int64_t
encodedDataSize) {}
On 2016/06/28 15:35:08, kinuko wrote:
> encodedDataLength?

Fixed, thanks.

[Adam Rice, 2016-06-29 09:53:13]

On 2016/06/29 06:59:38, Yoav Weiss wrote:
> Any particular reason for the layout tests to be in a separate CL?

No profound reason. I wrote them first, and it has been easier for me to
manage them in a separate branch.

[Kunihiko Sakamoto, 2016-06-30 10:19:48]

ksakamoto@chromium.org changed reviewers:
+ ksakamoto@chromium.org

[Kunihiko Sakamoto, 2016-06-30 10:19:49]

Drive-by comment.

https://codereview.chromium.org/2105713002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl
(right):

https://codereview.chromium.org/2105713002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl:49: readonly
attribute unsigned short transferSize;
The spec says these fields are unsigned long long.

[Adam Rice, 2016-06-30 10:29:58]

https://codereview.chromium.org/2105713002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl
(right):

https://codereview.chromium.org/2105713002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceResourceTiming.idl:49: readonly
attribute unsigned short transferSize;
On 2016/06/30 10:19:49, Kunihiko Sakamoto wrote:
> The spec says these fields are unsigned long long.

Wow. I don't know how I managed to get that wrong. Thanks for catching it.
Fixed.

[Adam Rice, 2016-07-01 07:32:04]

kinuko, I've added tests for the redirect cases to ResourceLoader. I found a bug
in the process, so it was worthwhile.

I also added a test for Sync XHR, since I found that was broken for the second
time.

PTAL.

[kinuko, 2016-07-01 07:38:33]

Thanks, will take a look.

(Sakamoto-san, when you have time could you also review the changes?)

[Kunihiko Sakamoto, 2016-07-01 10:12:35]

https://codereview.chromium.org/2105713002/diff/60001/chrome/renderer/extensi...
File chrome/renderer/extensions/extension_localization_peer.cc (right):

https://codereview.chromium.org/2105713002/diff/60001/chrome/renderer/extensi...
chrome/renderer/extensions/extension_localization_peer.cc:30: int
encoded_length() const override { return -1; }
encoded_data_length?

https://codereview.chromium.org/2105713002/diff/60001/chrome/renderer/extensi...
chrome/renderer/extensions/extension_localization_peer.cc:33: int
encoded_body_length() const override { return data.size(); }
s/data/data_/

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:1066: bool crossOrigin
= !redirectedSecurityOrigin->canRequest(newRequest.url());
This is just a same-origin check rather than a permission check, I feel
isSameSchemeHostPort() is more appropriate here.

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp:485: // The magic
number "300" is specified as the redirect overhead in
Can you define this magic number as a constant?

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/network/ResourceTimingInfo.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/network/ResourceTimingInfo.cpp:44: if
(crossOrigin && !m_hasCrossOriginRedirect) {
Early return if m_hasCrossOriginRedirect is true?

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/AssociatedURLLoader.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/AssociatedURLLoader.cpp:152: // FIXME: Set
encodedDataLength
I believe TODO(someone) is now preferred over FIXME.

[Adam Rice, 2016-07-04 02:44:18]

https://codereview.chromium.org/2105713002/diff/60001/chrome/renderer/extensi...
File chrome/renderer/extensions/extension_localization_peer.cc (right):

https://codereview.chromium.org/2105713002/diff/60001/chrome/renderer/extensi...
chrome/renderer/extensions/extension_localization_peer.cc:30: int
encoded_length() const override { return -1; }
On 2016/07/01 10:12:35, Kunihiko Sakamoto wrote:
> encoded_data_length?

Done. Sorry for making you act as a human compiler. I should have run try jobs.

https://codereview.chromium.org/2105713002/diff/60001/chrome/renderer/extensi...
chrome/renderer/extensions/extension_localization_peer.cc:33: int
encoded_body_length() const override { return data.size(); }
On 2016/07/01 10:12:35, Kunihiko Sakamoto wrote:
> s/data/data_/

Done.

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:1066: bool crossOrigin
= !redirectedSecurityOrigin->canRequest(newRequest.url());
On 2016/07/01 10:12:35, Kunihiko Sakamoto wrote:
> This is just a same-origin check rather than a permission check, I feel
> isSameSchemeHostPort() is more appropriate here.

Done.

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp:485: // The magic
number "300" is specified as the redirect overhead in
On 2016/07/01 10:12:35, Kunihiko Sakamoto wrote:
> Can you define this magic number as a constant?

Done.

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/network/ResourceTimingInfo.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/network/ResourceTimingInfo.cpp:44: if
(crossOrigin && !m_hasCrossOriginRedirect) {
On 2016/07/01 10:12:35, Kunihiko Sakamoto wrote:
> Early return if m_hasCrossOriginRedirect is true?

Done, thanks.

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/AssociatedURLLoader.cpp (right):

https://codereview.chromium.org/2105713002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/AssociatedURLLoader.cpp:152: // FIXME: Set
encodedDataLength
On 2016/07/01 10:12:35, Kunihiko Sakamoto wrote:
> I believe TODO(someone) is now preferred over FIXME.

Done.

[kinuko, 2016-07-04 04:08:12]

Haven't done thorough review yet, esp. for new tests, but sending out some
comments... (also: if we don't have strong reasons other than CL getting too
large I think it's generally better to land the change with layout tests.  But
we can revisit it later as we're still iterating over the main change...)

https://codereview.chromium.org/2105713002/diff/80001/content/child/shared_me...
File content/child/shared_memory_received_data_factory.h (right):

https://codereview.chromium.org/2105713002/diff/80001/content/child/shared_me...
content/child/shared_memory_received_data_factory.h:36: int encoded_length,
nit: encoded_data_length

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
content/public/child/request_peer.h:47: // original thread.
nit: weird line wrapping

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
content/public/child/request_peer.h:58: virtual int encoded_data_length() const
= 0;
We often seem to set this to -1 in tests and also in some code paths (while not
for other fields), should it be explicitly communicated here?  (I'm not fully
sure why we specifically use -1 for this one)

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
content/public/child/request_peer.h:60: // network or stored in the disk cache.
This will be different from the data
'excluding headers' ...?

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebURLLoaderClient.h (right):

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebURLLoaderClient.h:47: // generated by the
redirect. The client may modify |newRequest|.
could we update the comment?

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebURLLoaderClient.h:71: // Called when a
chunk of response data is received.
Ditto.

Also: similar to other comments, we seem to often pass in -1 or 0 as
encodedDataLength when it's unknown or not applicable... is it possible to be
consistent here and (or at least) explicitly comment what should be passed in in
such cases?

(Contrary to this one for willFollowRedirect we basically seem to pass in 0 in
various tests, which feels also confusing to me and would be better if it's
documented)

[Adam Rice, 2016-07-04 06:33:43]

I will need to rebase at some point because the try bots can no longer apply the
patch. It is no problem to wait until you are finished reviewing.

https://codereview.chromium.org/2105713002/diff/80001/content/child/shared_me...
File content/child/shared_memory_received_data_factory.h (right):

https://codereview.chromium.org/2105713002/diff/80001/content/child/shared_me...
content/child/shared_memory_received_data_factory.h:36: int encoded_length,
On 2016/07/04 04:08:12, kinuko wrote:
> nit: encoded_data_length

Done.

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
content/public/child/request_peer.h:47: // original thread.
On 2016/07/04 04:08:12, kinuko wrote:
> nit: weird line wrapping

Fixed.

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
content/public/child/request_peer.h:58: virtual int encoded_data_length() const
= 0;
On 2016/07/04 04:08:12, kinuko wrote:
> We often seem to set this to -1 in tests and also in some code paths (while
not
> for other fields), should it be explicitly communicated here?  (I'm not fully
> sure why we specifically use -1 for this one)

I have added a comment that "-1 means this value is unavailable." It appears
that in practice 0 means "no data was received over the network for this chunk"
but that doesn't appear to be explicitly documented anywhere.

Since this field is actually an incremental value for just this chunk, -1 is
probably not a good idea, but I will have to audit all consumers of this value
to be sure we can change the semantics safely.

https://codereview.chromium.org/2105713002/diff/80001/content/public/child/re...
content/public/child/request_peer.h:60: // network or stored in the disk cache.
This will be different from the data
On 2016/07/04 04:08:12, kinuko wrote:
> 'excluding headers' ...?

Added.

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/publ...
File third_party/WebKit/public/platform/WebURLLoaderClient.h (right):

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebURLLoaderClient.h:47: // generated by the
redirect. The client may modify |newRequest|.
On 2016/07/04 04:08:12, kinuko wrote:
> could we update the comment?

Done.

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/publ...
third_party/WebKit/public/platform/WebURLLoaderClient.h:71: // Called when a
chunk of response data is received.
On 2016/07/04 04:08:12, kinuko wrote:
> Ditto.
> 
> Also: similar to other comments, we seem to often pass in -1 or 0 as
> encodedDataLength when it's unknown or not applicable... is it possible to be
> consistent here and (or at least) explicitly comment what should be passed in
in
> such cases?
> 
> (Contrary to this one for willFollowRedirect we basically seem to pass in 0 in
> various tests, which feels also confusing to me and would be better if it's
> documented)

I have documented this method as taking -1 when the information is unavailable.
For the same reason as with ReceivedData, I think this is undesirable and I
would like to change it.

[Kunihiko Sakamoto, 2016-07-04 06:59:05]

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:1066:
RefPtr<SecurityOrigin> originalSecurityOrigin =
SecurityOrigin::create(newRequest.url());
Wrong variable names?  If I'm not mistaken, redirectResponse.url() is the
original URL and newRequest.url() is the redirected one.

[Adam Rice, 2016-07-04 07:36:45]

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/2105713002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:1066:
RefPtr<SecurityOrigin> originalSecurityOrigin =
SecurityOrigin::create(newRequest.url());
On 2016/07/04 06:59:04, Kunihiko Sakamoto wrote:
> Wrong variable names?  If I'm not mistaken, redirectResponse.url() is the
> original URL and newRequest.url() is the redirected one.

You are right. I was confused. Fixed.

[kinuko, 2016-07-07 05:11:40]

looking good, the comments made things a lot clearer now.

could we maybe start to pull in layout tests..?

https://codereview.chromium.org/2105713002/diff/120001/content/child/web_url_...
File content/child/web_url_loader_impl_unittest.cc (right):

https://codereview.chromium.org/2105713002/diff/120001/content/child/web_url_...
content/child/web_url_loader_impl_unittest.cc:715: EXPECT_EQ(17,
response.decodedBodyLength());
nit: Prefer getting this number (17) explicitly from the data (via strlen /
arraysize etc)

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:920: // FIXME: Find
cases where it is not available but the
FIXME -> TODO(ldap) now in blink too

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp (right):

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp:461: }
You can likely use
Platform::current()->getURLLoaderMockFactory()->unregisterAllURLs() ?

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp:466:
m_cachedResources.clear();
and memoryCache()->evictResources()

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/WebURLLoaderClient.h (right):

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/platform/WebURLLoaderClient.h:77: // from cache, and
-1 if this information is unavailable.
nit: does it make sense to have TODO to address this (a bit mysterious) -1
issue..?

[Adam Rice, 2016-07-07 07:39:37]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

Layout tests are in a separate CL: https://codereview.chromium.org/2045183002/

BUG=467945
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

BUG=467945
==========

[Adam Rice, 2016-07-07 07:40:01]

https://codereview.chromium.org/2105713002/diff/120001/content/child/web_url_...
File content/child/web_url_loader_impl_unittest.cc (right):

https://codereview.chromium.org/2105713002/diff/120001/content/child/web_url_...
content/child/web_url_loader_impl_unittest.cc:715: EXPECT_EQ(17,
response.decodedBodyLength());
On 2016/07/07 05:11:40, kinuko wrote:
> nit: Prefer getting this number (17) explicitly from the data (via strlen /
> arraysize etc)

Done.

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:920: // FIXME: Find
cases where it is not available but the
On 2016/07/07 05:11:40, kinuko wrote:
> FIXME -> TODO(ldap) now in blink too

Done.

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp (right):

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp:461: }
On 2016/07/07 05:11:40, kinuko wrote:
> You can likely use
> Platform::current()->getURLLoaderMockFactory()->unregisterAllURLs() ?

That is better, thank you.

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/ResourceFetcherTest.cpp:466:
m_cachedResources.clear();
On 2016/07/07 05:11:40, kinuko wrote:
> and memoryCache()->evictResources()

Thanks, done.

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/WebURLLoaderClient.h (right):

https://codereview.chromium.org/2105713002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/platform/WebURLLoaderClient.h:77: // from cache, and
-1 if this information is unavailable.
On 2016/07/07 05:11:40, kinuko wrote:
> nit: does it make sense to have TODO to address this (a bit mysterious) -1
> issue..?

Yes. I have added one.

[Kunihiko Sakamoto, 2016-07-07 09:56:51]

lgtm with comments

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cache.html
(right):

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cache.html:45:
}
Add assertion for seenCount value?

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-content-encoding.html
(right):

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-content-encoding.html:4:
<script src="/resources/get-host-info.js?pipe=sub"></script>
Is this necessary?

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-content-encoding.html:16:
if (entry.name === absoluteUrl) {
You can use performance.getEntriesByName(absoluteUrl) to skip this check.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html
(right):

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html:20:
var seenCount = 0;
nit: move this into checkResourceSizes()

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html:27:
entries.sort((a, b) => b.requestStart > a.requestStart ? 1 : -1);
nit: (a, b) => b.requestStart - a.requestStart  would be more concise.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html:31:
case 0:
-4 indent

[Adam Rice, 2016-07-07 11:21:12]

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cache.html
(right):

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cache.html:45:
}
On 2016/07/07 09:56:50, Kunihiko Sakamoto wrote:
> Add assertion for seenCount value?

I switched to using getEntriesByName(url) and added an assertion for
entries.length instead.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-content-encoding.html
(right):

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-content-encoding.html:4:
<script src="/resources/get-host-info.js?pipe=sub"></script>
On 2016/07/07 09:56:51, Kunihiko Sakamoto wrote:
> Is this necessary?

Removed, thanks.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-content-encoding.html:16:
if (entry.name === absoluteUrl) {
On 2016/07/07 09:56:50, Kunihiko Sakamoto wrote:
> You can use performance.getEntriesByName(absoluteUrl) to skip this check.

That's better, thank you.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html
(right):

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html:20:
var seenCount = 0;
On 2016/07/07 09:56:51, Kunihiko Sakamoto wrote:
> nit: move this into checkResourceSizes()

Done.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html:27:
entries.sort((a, b) => b.requestStart > a.requestStart ? 1 : -1);
On 2016/07/07 09:56:51, Kunihiko Sakamoto wrote:
> nit: (a, b) => b.requestStart - a.requestStart  would be more concise.

Done.

https://codereview.chromium.org/2105713002/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/misc/resource-timing-sizes-cors-preflight.html:31:
case 0:
On 2016/07/07 09:56:51, Kunihiko Sakamoto wrote:
> -4 indent

Done.

[Adam Rice, 2016-07-12 07:11:14]

The CQ bit was checked by ricea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 07:11:46]

Dry run: 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-07-12 07:24:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-12 07:24:10]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Adam Rice, 2016-07-12 07:41:01]

The CQ bit was checked by ricea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 07:41:34]

Dry run: 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-07-12 07:57:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-12 07:57:03]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[Adam Rice, 2016-07-12 09:49:19]

The CQ bit was checked by ricea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 09:49:53]

Dry run: 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-07-12 10:20:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-12 10:20:45]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[kinuko, 2016-07-14 02:17:33]

I've been waiting for this CL to be rebased on the browser-side changes, is it
ready now? (Looks like we still have some build errors, though I can resume
reviewing)

[Adam Rice, 2016-07-14 02:53:45]

On 2016/07/14 02:17:33, kinuko wrote:
> I've been waiting for this CL to be rebased on the browser-side changes, is it
> ready now? (Looks like we still have some build errors, though I can resume
> reviewing)

Sorry for the delay.

The rebase is done. Because the CQ was slow, it's actually rebased against
ToT + the browser changes separately, but that shouldn't make any difference.
I have been working to debug the mysterious test failures on
win bots. The win_clang compile error is simple, I will fix it.

[kinuko, 2016-07-14 05:04:12]

ok thanks I think this lgtm

[Adam Rice, 2016-07-14 06:12:24]

The CQ bit was checked by ricea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 06:12:41]

Dry run: 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-07-14 06:15:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-14 06:15:07]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-gn/bui...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)

[Adam Rice, 2016-07-14 11:42:52]

The CQ bit was checked by ricea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 11:43:12]

Dry run: 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-07-14 13:15:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-14 13:15:46]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Adam Rice, 2016-07-15 03:49:28]

The CQ bit was checked by ricea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-15 03:49:53]

Dry run: 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-07-15 05:24:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-15 05:24:32]

Dry run: This issue passed the CQ dry run.

[Adam Rice, 2016-07-15 05:32:58]

ricea@chromium.org changed reviewers:
+ jochen@chromium.org

[Adam Rice, 2016-07-15 05:32:59]

+jochen for API OWNERS.

Feature URL is https://www.chromestatus.com/feature/6549060404117504

[jochen (gone - plz use gerrit), 2016-07-15 14:37:17]

can you please add the link to the approved intent to ship to the CL
description?

[Adam Rice, 2016-07-19 02:45:30]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

BUG=467945
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
==========

[Adam Rice, 2016-07-19 02:45:56]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
==========

[Adam Rice, 2016-07-19 02:46:20]

On 2016/07/15 14:37:17, jochen wrote:
> can you please add the link to the approved intent to ship to the CL
> description?

Link added, thanks.

[jochen (gone - plz use gerrit), 2016-07-19 12:25:05]

lgtm

[Adam Rice, 2016-07-20 05:13:55]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato
==========

[Adam Rice, 2016-07-20 05:14:42]

ricea@chromium.org changed reviewers:
+ liberato@chromium.org

[Adam Rice, 2016-07-20 05:14:44]

TBR liberato for //media OWNERS.

[Adam Rice, 2016-07-20 05:14:56]

The CQ bit was checked by ricea@chromium.org

[Adam Rice, 2016-07-20 05:14:57]

The patchset sent to the CQ was uploaded after l-g-t-m from
ksakamoto@chromium.org, kinuko@chromium.org
Link to the patchset: https://codereview.chromium.org/2105713002/#ps330001
(title: "Initialise encoded_body_length for sync XHR to data: URLs")

[commit-bot: I haz the power, 2016-07-20 05:15:10]

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-07-20 05:22:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-20 05:22:25]

Try jobs failed on following builders:
  win8_chromium_gyp_rel on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gyp...)

[Adam Rice, 2016-07-20 07:24:20]

The CQ bit was checked by ricea@chromium.org

[commit-bot: I haz the power, 2016-07-20 07:24:42]

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-07-20 12:53:49]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato
==========

[commit-bot: I haz the power, 2016-07-20 12:53:51]

Committed patchset #18 (id:330001)

[commit-bot: I haz the power, 2016-07-20 12:57:01]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato

Committed: https://crrev.com/d91ea73de426248bf5d8524da38c07c0a6b34b19
Cr-Commit-Position: refs/heads/master@{#406527}
==========

[commit-bot: I haz the power, 2016-07-20 12:57:03]

Patchset 18 (id:??) landed as
https://crrev.com/d91ea73de426248bf5d8524da38c07c0a6b34b19
Cr-Commit-Position: refs/heads/master@{#406527}

[liberato (no reviews please), 2016-07-20 15:38:13]

Description was changed from

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato

Committed: https://crrev.com/d91ea73de426248bf5d8524da38c07c0a6b34b19
Cr-Commit-Position: refs/heads/master@{#406527}
==========

to

==========
Render process changes for ResourceTiming sizes.

This is part of the changes to add the size fields to the
PerformanceResourceTiming API.

Intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1bdP80f0GVs/U7qIckr-...

These are the render process changes which take the "encodedBodySize" and
"transferSize" fields that were received from the browser and make them
available on the PerformanceResourceTiming object.

In addition, code is added to track the "decodedBodySize" by summing all the
data bytes that are read from the browser process, and this is also made
available on the PerformanceResourceTiming object.

See the design doc at
https://docs.google.com/document/d/1ckL-rKLFRsdI4nn1golvQ6I1zRIvxgFkDXMrZb8Kd...
for a far more detailed description of the changes.

BUG=467945
TBR=liberato

Committed: https://crrev.com/d91ea73de426248bf5d8524da38c07c0a6b34b19
Cr-Commit-Position: refs/heads/master@{#406527}
==========

[liberato (no reviews please), 2016-07-20 15:38:13]

liberato@chromium.org changed reviewers:
+ hubbe@chromium.org
- liberato@chromium.org

[liberato (no reviews please), 2016-07-20 15:40:09]

On 2016/07/20 05:14:44, Adam Rice wrote:
> TBR liberato for //media OWNERS.

replacing myself with hubbe, who wrote multibuffer.

[hubbe, 2016-07-20 17:19:57]

On 2016/07/20 15:40:09, liberato wrote:
> On 2016/07/20 05:14:44, Adam Rice wrote:
> > TBR liberato for //media OWNERS.
> 
> replacing myself with hubbe, who wrote multibuffer.

media/* LGTM

[hubbe, 2016-07-20 17:20:36]

LGTM for media/*