Make WebURLLoader capable of retaining received buffers.

Make WebURLLoader capable of retaining received buffers.

In order to implement backpressure on resource loading, this CL
makes WebURLLoader capable of retaining received buffers. In the
current implementation, ResourceDispatcher takes care of the buffer
lifetime in OnReceivedData. With this CL, it passes a ReceivedData
object that contains payload, length and encoded_length. The difference
is that a ReceivedData object keeps payload valid while it is alive,
so we can store the buffer if we like (with care, of course).

This CL does not change the behavior, except one: it replaces a possible
use-after-free in ResourceDispatcher::OnReceivedData when using
|alternative_data| with |threaded_data_provider| with an incorrect
, but safe operation.

BUG=480746
Committed: https://crrev.com/65d393906dd7532c51bbb70c9c181eae3b1e1758
Cr-Commit-Position: refs/heads/master@{#332512}

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

[yhirano, 2015-04-24 03:30:54]

Patchset #4 (id:60001) has been deleted

[yhirano, 2015-04-24 04:25:32]

Patchset #4 (id:80001) has been deleted

[yhirano, 2015-04-24 06:52:19]

yhirano@chromium.org changed reviewers:
+ tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2015-04-27 05:20:16]

https://codereview.chromium.org/1103813002/diff/140001/content/child/web_url_...
File content/child/web_url_loader_impl.cc (right):

https://codereview.chromium.org/1103813002/diff/140001/content/child/web_url_...
content/child/web_url_loader_impl.cc:849: make_scoped_ptr(new
FixedReceivedData(data.c_str(), data.size(), 0)));
why c_str?

https://codereview.chromium.org/1103813002/diff/140001/content/public/child/r...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/1103813002/diff/140001/content/public/child/r...
content/public/child/request_peer.h:45: // The encoded_data_length is the length
of the encoded data transferred
encoded_length

[yhirano, 2015-04-27 05:29:38]

https://codereview.chromium.org/1103813002/diff/140001/content/child/web_url_...
File content/child/web_url_loader_impl.cc (right):

https://codereview.chromium.org/1103813002/diff/140001/content/child/web_url_...
content/child/web_url_loader_impl.cc:849: make_scoped_ptr(new
FixedReceivedData(data.c_str(), data.size(), 0)));
On 2015/04/27 05:20:15, tyoshino wrote:
> why c_str?

Done.

https://codereview.chromium.org/1103813002/diff/140001/content/public/child/r...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/1103813002/diff/140001/content/public/child/r...
content/public/child/request_peer.h:45: // The encoded_data_length is the length
of the encoded data transferred
On 2015/04/27 05:20:15, tyoshino wrote:
> encoded_length

Done.

[tyoshino (SeeGerritForStatus), 2015-04-27 07:19:29]

https://codereview.chromium.org/1103813002/diff/160001/chrome/renderer/securi...
File chrome/renderer/security_filter_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/160001/chrome/renderer/securi...
chrome/renderer/security_filter_peer.cc:20: const char* payload() const override
{ return data_.c_str(); }
needs to be c_str?

https://codereview.chromium.org/1103813002/diff/160001/content/child/ref_coun...
File content/child/ref_counted_shared_memory.h (right):

https://codereview.chromium.org/1103813002/diff/160001/content/child/ref_coun...
content/child/ref_counted_shared_memory.h:32: #endif  // #ifndef
CONTENT_REF_COUNTED_SHARED_MEMORY_H_
remove "#ifndef "

[yhirano, 2015-04-28 06:31:44]

Patchset #8 (id:180001) has been deleted

[yhirano, 2015-04-28 06:51:01]

Patchset #8 (id:200001) has been deleted

[yhirano, 2015-04-28 09:31:40]

Patchset #8 (id:220001) has been deleted

[yhirano, 2015-04-28 09:43:59]

I found that shared memory reclaiming was wrong, so fixed the problem at PS8.
Can you take a look again?

I'm not 100% sure about DCHECKs at resource_dispatcher.cc:L272-L273, but I'm
asking the question separately[1].

https://codereview.chromium.org/1107043003/

Thanks!

https://codereview.chromium.org/1103813002/diff/160001/chrome/renderer/securi...
File chrome/renderer/security_filter_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/160001/chrome/renderer/securi...
chrome/renderer/security_filter_peer.cc:20: const char* payload() const override
{ return data_.c_str(); }
On 2015/04/27 07:19:29, tyoshino wrote:
> needs to be c_str?

No. Fixed.

https://codereview.chromium.org/1103813002/diff/160001/content/child/ref_coun...
File content/child/ref_counted_shared_memory.h (right):

https://codereview.chromium.org/1103813002/diff/160001/content/child/ref_coun...
content/child/ref_counted_shared_memory.h:32: #endif  // #ifndef
CONTENT_REF_COUNTED_SHARED_MEMORY_H_
On 2015/04/27 07:19:29, tyoshino wrote:
> remove "#ifndef "

Deleted.

[yhirano, 2015-04-28 10:34:39]

Patchset #8 (id:240001) has been deleted

[yhirano, 2015-04-30 06:07:48]

Patchset #12 (id:340001) has been deleted

[tyoshino (SeeGerritForStatus), 2015-05-01 08:09:07]

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
File chrome/renderer/extensions/extension_localization_peer_unittest.cc (right):

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:6: #include
<string>
vector

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:207:
OnReceivedDataInternal(StrEq(data.data()), data.length(), -1))
should be c_str?

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:244:
OnReceivedDataInternal(StrEq(data.data()), data.length(), -1));
ditto

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:272:
EXPECT_CALL(*original_peer_, OnReceivedDataInternal(StrEq(message.data()),
ditto

[yhirano, 2015-05-01 09:58:52]

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
File chrome/renderer/extensions/extension_localization_peer_unittest.cc (right):

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:6: #include
<string>
On 2015/05/01 08:09:07, tyoshino wrote:
> vector

Done.

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:207:
OnReceivedDataInternal(StrEq(data.data()), data.length(), -1))
On 2015/05/01 08:09:07, tyoshino wrote:
> should be c_str?

Done.

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:244:
OnReceivedDataInternal(StrEq(data.data()), data.length(), -1));
On 2015/05/01 08:09:07, tyoshino wrote:
> ditto

Done.

https://codereview.chromium.org/1103813002/diff/380001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer_unittest.cc:272:
EXPECT_CALL(*original_peer_, OnReceivedDataInternal(StrEq(message.data()),
On 2015/05/01 08:09:07, tyoshino wrote:
> ditto

Done.

[yhirano, 2015-05-20 06:57:35]

ping

[tyoshino (SeeGerritForStatus), 2015-05-27 03:45:34]

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
File chrome/renderer/extensions/extension_localization_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer.cc:24: const char*
payload() const override { return data_.c_str(); }
data_.data()

[tyoshino (SeeGerritForStatus), 2015-05-27 03:52:54]

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
File chrome/renderer/extensions/extension_localization_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer.cc:24: const char*
payload() const override { return data_.c_str(); }
On 2015/05/27 03:45:34, tyoshino wrote:
> data_.data()

Oh, we still need &data_[0]?

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
// TODO(yhirano): Use |data_.data()| when we can use c++11.

[tyoshino (SeeGerritForStatus), 2015-05-27 03:53:22]

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
File chrome/renderer/extensions/extension_localization_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer.cc:24: const char*
payload() const override { return data_.c_str(); }
On 2015/05/27 03:52:54, tyoshino wrote:
> On 2015/05/27 03:45:34, tyoshino wrote:
> > data_.data()
> 
> Oh, we still need &data_[0]?
> 
>
https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
> // TODO(yhirano): Use |data_.data()| when we can use c++11.

Sorry. It was vector...

[tyoshino (SeeGerritForStatus), 2015-05-27 04:32:08]

https://codereview.chromium.org/1103813002/diff/400001/content/child/resource...
File content/child/resource_dispatcher.cc (right):

https://codereview.chromium.org/1103813002/diff/400001/content/child/resource...
content/child/resource_dispatcher.cc:274: // data may be processed later on
another thread.
write the reason why we can stop using alternative_data temporary in the CL
description

https://codereview.chromium.org/1103813002/diff/400001/content/child/resource...
content/child/resource_dispatcher.cc:288: if (data)
Can data be null?

[yhirano, 2015-05-27 04:51:37]

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
File chrome/renderer/extensions/extension_localization_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
chrome/renderer/extensions/extension_localization_peer.cc:24: const char*
payload() const override { return data_.c_str(); }
On 2015/05/27 03:53:22, tyoshino wrote:
> On 2015/05/27 03:52:54, tyoshino wrote:
> > On 2015/05/27 03:45:34, tyoshino wrote:
> > > data_.data()
> > 
> > Oh, we still need &data_[0]?
> > 
> >
>
https://codereview.chromium.org/1103813002/diff/400001/chrome/renderer/extens...
> > // TODO(yhirano): Use |data_.data()| when we can use c++11.
> 
> Sorry. It was vector...

Done.

https://codereview.chromium.org/1103813002/diff/400001/content/child/resource...
File content/child/resource_dispatcher.cc (right):

https://codereview.chromium.org/1103813002/diff/400001/content/child/resource...
content/child/resource_dispatcher.cc:274: // data may be processed later on
another thread.
On 2015/05/27 04:32:08, tyoshino wrote:
> write the reason why we can stop using alternative_data temporary in the CL
> description

Done. Note that I don't break a working code here: If |alternative_data| is used
with |threaded_data_provider|, it leads to a UAF.

https://codereview.chromium.org/1103813002/diff/400001/content/child/resource...
content/child/resource_dispatcher.cc:288: if (data)
On 2015/05/27 04:32:08, tyoshino wrote:
> Can data be null?

Done.

[tyoshino (SeeGerritForStatus), 2015-05-27 06:14:18]

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
File content/child/shared_memory_received_data_factory.cc (right):

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory.cc:88: return (oldest_ <= x);
when does this happen?

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory.cc:124: SendAck(1);
I prefer incrementing before adding count unless there's any reason to process
the count for newer ones before the oldest one.

[yhirano, 2015-05-27 06:24:26]

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
File content/child/shared_memory_received_data_factory.cc (right):

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory.cc:88: return (oldest_ <= x);
On 2015/05/27 06:14:18, tyoshino wrote:
> when does this happen?

It happens when 2 ^ 32 or more tickets are issued. This class is designed to
work in such a case, as written in the comment at
shared_memory_received_data_factory.h:39.

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory.cc:124: SendAck(1);
On 2015/05/27 06:14:18, tyoshino wrote:
> I prefer incrementing before adding count unless there's any reason to process
> the count for newer ones before the oldest one.

I'd like to avoid |count| overflow here.

[yhirano, 2015-05-27 07:14:35]

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
File content/child/shared_memory_received_data_factory.cc (right):

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory.cc:124: SendAck(1);
On 2015/05/27 06:24:26, yhirano wrote:
> On 2015/05/27 06:14:18, tyoshino wrote:
> > I prefer incrementing before adding count unless there's any reason to
process
> > the count for newer ones before the oldest one.
> 
> I'd like to avoid |count| overflow here.

Fixed as discussed offline.

[tyoshino (SeeGerritForStatus), 2015-05-27 07:36:49]

lgtm

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
File content/child/shared_memory_received_data_factory_unittest.cc (right):

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory_unittest.cc:11: 
add scoped_ptr, etc.

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory_unittest.cc:48:
memory_.reset(new base::SharedMemory),
why comma?

[yhirano, 2015-05-27 08:35:11]

Patchset #17 (id:460001) has been deleted

[yhirano, 2015-05-27 08:39:54]

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
File content/child/shared_memory_received_data_factory_unittest.cc (right):

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory_unittest.cc:11: 
On 2015/05/27 07:36:49, tyoshino wrote:
> add scoped_ptr, etc.

Added some. scoped_ptr, etc are already included in
shared_memory_received_data_factory.h.

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory_unittest.cc:48:
memory_.reset(new base::SharedMemory),
On 2015/05/27 07:36:49, tyoshino wrote:
> why comma?

Thanks, fixed.

[yhirano, 2015-05-27 08:55:16]

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

[yhirano, 2015-05-27 08:55:17]

+jochen for OWNER review.

[tyoshino (SeeGerritForStatus), 2015-05-27 09:32:03]

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
File content/child/shared_memory_received_data_factory_unittest.cc (right):

https://codereview.chromium.org/1103813002/diff/420001/content/child/shared_m...
content/child/shared_memory_received_data_factory_unittest.cc:11: 
On 2015/05/27 08:39:54, yhirano wrote:
> On 2015/05/27 07:36:49, tyoshino wrote:
> > add scoped_ptr, etc.
> 
> Added some. scoped_ptr, etc are already included in
> shared_memory_received_data_factory.h.

https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Names_and_Or...

"However, any includes present in the related header do not need to be included
again in the related cc (i.e., foo.cc can rely on foo.h's includes)."

I've been applying this exception only for combinations of foo.h and foo.cc, not
foo_unittest.cc. Doing so means that we should take a look at unittest files
when we remove includes from .h file. Maybe, ok, ... but I'm trying to do IWYU
in unittest files too.

It's not clear in the style guide. Up to your judgement.

[jochen (gone - plz use gerrit), 2015-05-27 15:09:22]

can we have a central received data implementation? having all those slightly
different holders of strings looks error prone to me

[yhirano, 2015-05-27 16:06:02]

On 2015/05/27 15:09:22, jochen wrote:
> can we have a central received data implementation? having all those slightly
> different holders of strings looks error prone to me

It is a good idea, but where should the code be located?

[jochen (gone - plz use gerrit), 2015-05-28 14:35:40]

maybe just make ReceivedData a concrete class?

or if it's only a string for tests content/public/test ?

[yhirano, 2015-06-01 05:39:28]

Patchset #18 (id:500001) has been deleted

[yhirano, 2015-06-01 05:39:54]

Patchset #18 (id:520001) has been deleted

[yhirano, 2015-06-01 06:50:04]

On 2015/05/28 14:35:40, jochen wrote:
> maybe just make ReceivedData a concrete class?
> 
> or if it's only a string for tests content/public/test ?

I added FixedReceivedData declaration to request_peer.h and defined it on
newly-created request_peer.cc. PTAL.

[jochen (gone - plz use gerrit), 2015-06-01 13:08:28]

https://codereview.chromium.org/1103813002/diff/540001/content/child/request_...
File content/child/request_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/540001/content/child/request_...
content/child/request_peer.cc:5: #include "content/public/child/request_peer.h"
this file should go into content/public/child

https://codereview.chromium.org/1103813002/diff/540001/content/child/web_url_...
File content/child/web_url_loader_impl.cc (right):

https://codereview.chromium.org/1103813002/diff/540001/content/child/web_url_...
content/child/web_url_loader_impl.cc:76: using FixedReceivedData =
RequestPeer::FixedReceivedData;
please don't use "using" - we only use that to help with refactoring, new code
should always use the full names

https://codereview.chromium.org/1103813002/diff/540001/content/public/child/r...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/1103813002/diff/540001/content/public/child/r...
content/public/child/request_peer.h:56: class CONTENT_EXPORT FixedReceivedData
final : public ReceivedData {
hum, that looks a bit odd, maybe content/public/child/fixed_received_data.h ?

[yhirano, 2015-06-02 02:08:48]

https://codereview.chromium.org/1103813002/diff/540001/content/child/request_...
File content/child/request_peer.cc (right):

https://codereview.chromium.org/1103813002/diff/540001/content/child/request_...
content/child/request_peer.cc:5: #include "content/public/child/request_peer.h"
On 2015/06/01 13:08:28, jochen wrote:
> this file should go into content/public/child

Done.

https://codereview.chromium.org/1103813002/diff/540001/content/child/web_url_...
File content/child/web_url_loader_impl.cc (right):

https://codereview.chromium.org/1103813002/diff/540001/content/child/web_url_...
content/child/web_url_loader_impl.cc:76: using FixedReceivedData =
RequestPeer::FixedReceivedData;
On 2015/06/01 13:08:28, jochen wrote:
> please don't use "using" - we only use that to help with refactoring, new code
> should always use the full names

Done.

https://codereview.chromium.org/1103813002/diff/540001/content/public/child/r...
File content/public/child/request_peer.h (right):

https://codereview.chromium.org/1103813002/diff/540001/content/public/child/r...
content/public/child/request_peer.h:56: class CONTENT_EXPORT FixedReceivedData
final : public ReceivedData {
On 2015/06/01 13:08:28, jochen wrote:
> hum, that looks a bit odd, maybe content/public/child/fixed_received_data.h ?

Done.

[jochen (gone - plz use gerrit), 2015-06-02 16:15:36]

lgtm thx

[yhirano, 2015-06-03 00:39:23]

Thanks!

[yhirano, 2015-06-03 00:39:30]

The CQ bit was checked by yhirano@chromium.org

[yhirano, 2015-06-03 00:39:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
tyoshino@chromium.org
Link to the patchset: https://codereview.chromium.org/1103813002/#ps560001
(title: " ")

[commit-bot: I haz the power, 2015-06-03 00:40:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1103813002/560001

[commit-bot: I haz the power, 2015-06-03 00:47:27]

Committed patchset #19 (id:560001)

[commit-bot: I haz the power, 2015-06-03 00:48:24]

Patchset 19 (id:??) landed as
https://crrev.com/65d393906dd7532c51bbb70c9c181eae3b1e1758
Cr-Commit-Position: refs/heads/master@{#332512}

[M-A Ruel, 2015-06-03 01:13:44]

A revert of this CL (patchset #19 id:560001) has been created in
https://codereview.chromium.org/1159113009/ by maruel@chromium.org.

The reason for reverting is: It broke Win x64 GN (dbg)
http://build.chromium.org/p/chromium.win/builders/Win%20x64%20GN%20%28dbg%29/...

e:\b\build\slave\win_x64_gn__dbg_\build\src\content\public\child\fixed_received_data.cc(34)
:error C2220: warning treated as error - no 'object' file generated
e:\b\build\slave\win_x64_gn__dbg_\build\src\content\public\child\fixed_received_data.cc(34)
: warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of
data.

[yhirano, 2015-06-03 01:27:36]

On 2015/06/03 01:13:44, M-A Ruel wrote:
> A revert of this CL (patchset #19 id:560001) has been created in
> https://codereview.chromium.org/1159113009/ by mailto:maruel@chromium.org.
> 
> The reason for reverting is: It broke Win x64 GN (dbg)
>
http://build.chromium.org/p/chromium.win/builders/Win%20x64%20GN%20%28dbg%29/...
> 
>
e:\b\build\slave\win_x64_gn__dbg_\build\src\content\public\child\fixed_received_data.cc(34)
> :error C2220: warning treated as error - no 'object' file generated
>
e:\b\build\slave\win_x64_gn__dbg_\build\src\content\public\child\fixed_received_data.cc(34)
> : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss
of
> data.

Reopen.

[yhirano, 2015-06-03 04:42:51]

On 2015/06/03 01:27:36, yhirano wrote:
> On 2015/06/03 01:13:44, M-A Ruel wrote:
> > A revert of this CL (patchset #19 id:560001) has been created in
> > https://codereview.chromium.org/1159113009/ by mailto:maruel@chromium.org.
> > 
> > The reason for reverting is: It broke Win x64 GN (dbg)
> >
>
http://build.chromium.org/p/chromium.win/builders/Win%20x64%20GN%20%28dbg%29/...
> > 
> >
>
e:\b\build\slave\win_x64_gn__dbg_\build\src\content\public\child\fixed_received_data.cc(34)
> > :error C2220: warning treated as error - no 'object' file generated
> >
>
e:\b\build\slave\win_x64_gn__dbg_\build\src\content\public\child\fixed_received_data.cc(34)
> > : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss
> of
> > data.
> 
> Reopen.

Fixed the build warning. Let me retry...

[yhirano, 2015-06-03 04:43:00]

The CQ bit was checked by yhirano@chromium.org

[yhirano, 2015-06-03 04:43:01]

The patchset sent to the CQ was uploaded after l-g-t-m from
tyoshino@chromium.org, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1103813002/#ps580001
(title: " ")

[commit-bot: I haz the power, 2015-06-03 04:44:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1103813002/580001

[commit-bot: I haz the power, 2015-06-03 04:50:00]

Committed patchset #20 (id:580001)

[commit-bot: I haz the power, 2015-06-03 04:50:46]

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