Add more unit tests for placeholder reloading

Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

ImageResourceTest.PartialContentWithoutDimensions
tests that DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests the case where DecodeError with non-empty body in
ResourceLoader::didFinishLoading() causes reloading.

BUG=667641, 677188
Review-Url: https://codereview.chromium.org/2648073002
Cr-Commit-Position: refs/heads/master@{#449776}
Committed: https://chromium.googlesource.com/chromium/src/+/6d03fad48660f6a6a767c6cc70c621ff10f8fcfa

[hiroshige, 2017-01-21 02:25:07]

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

[commit-bot: I haz the power, 2017-01-21 02:25:31]

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

[hiroshige, 2017-01-21 02:38:22]

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

[commit-bot: I haz the power, 2017-01-21 02:38:27]

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

[hiroshige, 2017-01-21 02:38:56]

Description was changed from

==========
Add a unit test for placeholder reloading on didFinishLoading

BUG=
==========

to

==========
Add a unit test for placeholder reloading on didFinishLoading

BUG=
==========

[commit-bot: I haz the power, 2017-01-21 04:23:26]

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

[commit-bot: I haz the power, 2017-01-21 04:23:27]

Dry run: This issue passed the CQ dry run.

[hiroshige, 2017-01-24 22:42:03]

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

[commit-bot: I haz the power, 2017-01-24 22:43:07]

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, 2017-01-25 00:47:18]

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

[commit-bot: I haz the power, 2017-01-25 00:47:19]

Dry run: This issue passed the CQ dry run.

[hiroshige, 2017-01-25 01:15:07]

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

[commit-bot: I haz the power, 2017-01-25 01:15:59]

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

[hiroshige, 2017-01-25 01:21:34]

Description was changed from

==========
Add a unit test for placeholder reloading on didFinishLoading

BUG=
==========

to

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests reloading caused by DecodeError in
ResourceLoader::didFinishLoading().

ImageResourceTest.PartialContentWithoutDimensions
tests the same response as
FetchAllowPlaceholderPartialContentWithoutDimensions but without
placeholder reloading, and thus tests that
DecodeError with non-empty body in ResourceLoader::didFinishLoading().

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

BUG=667641, 677188
==========

[hiroshige, 2017-01-25 02:03:24]

hiroshige@chromium.org changed reviewers:
+ sclittle@chromium.org, yhirano@chromium.org

[hiroshige, 2017-01-25 02:03:25]

PTAL
sclittle@ for LoFi/Placeholder reloading,
yhirano@ for loading.

[hiroshige, 2017-01-25 02:17:52]

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

[commit-bot: I haz the power, 2017-01-25 02:18:05]

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, 2017-01-25 04:11:38]

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

[commit-bot: I haz the power, 2017-01-25 04:11:39]

Dry run: This issue passed the CQ dry run.

[sclittle, 2017-01-27 21:56:06]

LGTM with nit

https://codereview.chromium.org/2648073002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
(right):

https://codereview.chromium.org/2648073002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1243:
TEST(ImageResourceTest, PartialContentWithoutDimensions) {
nit: Would it make sense to move this test up above, to just after
DecodeErrorWithEmptyBody? It just seems like it's more related to that test than
the placeholder tests here.

[hiroshige, 2017-02-06 22:50:38]

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

[hiroshige, 2017-02-06 22:50:45]

https://codereview.chromium.org/2648073002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
(right):

https://codereview.chromium.org/2648073002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1243:
TEST(ImageResourceTest, PartialContentWithoutDimensions) {
On 2017/01/27 21:56:06, sclittle wrote:
> nit: Would it make sense to move this test up above, to just after
> DecodeErrorWithEmptyBody? It just seems like it's more related to that test
than
> the placeholder tests here.

Done.

[commit-bot: I haz the power, 2017-02-06 22:51:17]

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

[hiroshige, 2017-02-06 23:04:35]

On 2017/02/06 22:50:45, hiroshige wrote:
>
https://codereview.chromium.org/2648073002/diff/120001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
> (right):
> 
>
https://codereview.chromium.org/2648073002/diff/120001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1243:
> TEST(ImageResourceTest, PartialContentWithoutDimensions) {
> On 2017/01/27 21:56:06, sclittle wrote:
> > nit: Would it make sense to move this test up above, to just after
> > DecodeErrorWithEmptyBody? It just seems like it's more related to that test
> than
> > the placeholder tests here.
> 
> Done.

yhirano@ PTAL as a core/loader OWNER.

[commit-bot: I haz the power, 2017-02-07 00:01:24]

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

[commit-bot: I haz the power, 2017-02-07 00:01:25]

Dry run: This issue passed the CQ dry run.

[yhirano, 2017-02-07 09:24:02]

Sorry for the late response.

Can you reorder the description so that it's aligned with the order in the test
file?

> ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
> tests reloading caused by DecodeError in ResourceLoader::didFinishLoading().

The reloading function is called directly by
ResourceFetcher::handleLoadCompletion, right?

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
(right):

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:984:
partialResponse.setHTTPStatusCode(206);
Why do you serve a partial response to a request with no "range" specified?

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1215:
TEST(ImageResourceTest, FetchAllowPlaceholderPartialContentWithoutDimensions) {
The server sends a response consisting of 3 bytes for a request requesting
0-2047 bytes, and it sends a response consisting of 300+ bytes for a request for
the same URL without a range header. Isn't this behavior strange?

[hiroshige, 2017-02-07 23:53:09]

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

[hiroshige, 2017-02-07 23:53:48]

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
(right):

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:984:
partialResponse.setHTTPStatusCode(206);
On 2017/02/07 09:24:02, yhirano wrote:
> Why do you serve a partial response to a request with no "range" specified?

Fixed.

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1215:
TEST(ImageResourceTest, FetchAllowPlaceholderPartialContentWithoutDimensions) {
On 2017/02/07 09:24:02, yhirano wrote:
> The server sends a response consisting of 3 bytes for a request requesting
> 0-2047 bytes, and it sends a response consisting of 300+ bytes for a request
for
> the same URL without a range header. Isn't this behavior strange?

Yes, strange, but in some of the other unit tests the server responds with
partial response of ~300 bytes for "bytes=0-2047" range requests (see
ReloadIfLoFiOrPlaceholderForPlaceholder, or the other uses of
kJpegImageSubrangeWithDimensionsLength).
How about filing a crbug and doing it later, as I feel it has lower priority and
doesn't affect Issue 667641 directly?
sclittle@, any thoughts?

To make this test consistent, we have to create a JPEG file with >2K that
doesn't contain image dimension information in the first 2KB, and make the
server to serve the first 2KB of that file for the first request, and serve the
whole file for the second request.
(I know there exists such a JPEG file but haven't constructed one yet)
Creating such a strange JPEG and testing it might be worth doing (valid but
extreme cases might be more likely to expose bugs!), but I don't want to have
Issue 667641 blocked by that.

[commit-bot: I haz the power, 2017-02-07 23:54:23]

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

[hiroshige, 2017-02-07 23:56:42]

Description was changed from

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests reloading caused by DecodeError in
ResourceLoader::didFinishLoading().

ImageResourceTest.PartialContentWithoutDimensions
tests the same response as
FetchAllowPlaceholderPartialContentWithoutDimensions but without
placeholder reloading, and thus tests that
DecodeError with non-empty body in ResourceLoader::didFinishLoading().

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

BUG=667641, 677188
==========

to

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

ImageResourceTest.PartialContentWithoutDimensions
tests that DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests reloading caused by DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

BUG=667641, 677188
==========

[hiroshige, 2017-02-08 00:00:26]

Description was changed from

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

ImageResourceTest.PartialContentWithoutDimensions
tests that DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests reloading caused by DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

BUG=667641, 677188
==========

to

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

ImageResourceTest.PartialContentWithoutDimensions
tests that DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests the case where DecodeError with non-empty body in
ResourceLoader::didFinishLoading() causes reloading.

BUG=667641, 677188
==========

[hiroshige, 2017-02-08 00:00:32]

> Can you reorder the description so that it's aligned with
> the order in the test file?
Done.

> The reloading function is called directly by
> ResourceFetcher::handleLoadCompletion, right?
Yes.
Reloading function itself is called directly by
ResourceFetcher::handleLoadCompletion(), but the reloading function actually
triggers the reloading because of DecodeError caused in didFinishLoading().
I rephrased the CL description to resolve the ambiguity.

[sclittle, 2017-02-08 00:32:59]

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
(right):

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1215:
TEST(ImageResourceTest, FetchAllowPlaceholderPartialContentWithoutDimensions) {
On 2017/02/07 23:53:48, hiroshige wrote:
> On 2017/02/07 09:24:02, yhirano wrote:
> > The server sends a response consisting of 3 bytes for a request requesting
> > 0-2047 bytes, and it sends a response consisting of 300+ bytes for a request
> for
> > the same URL without a range header. Isn't this behavior strange?
> 
> Yes, strange, but in some of the other unit tests the server responds with
> partial response of ~300 bytes for "bytes=0-2047" range requests (see
> ReloadIfLoFiOrPlaceholderForPlaceholder, or the other uses of
> kJpegImageSubrangeWithDimensionsLength).
> How about filing a crbug and doing it later, as I feel it has lower priority
and
> doesn't affect Issue 667641 directly?
> sclittle@, any thoughts?
> 
> To make this test consistent, we have to create a JPEG file with >2K that
> doesn't contain image dimension information in the first 2KB, and make the
> server to serve the first 2KB of that file for the first request, and serve
the
> whole file for the second request.
> (I know there exists such a JPEG file but haven't constructed one yet)
> Creating such a strange JPEG and testing it might be worth doing (valid but
> extreme cases might be more likely to expose bugs!), but I don't want to have
> Issue 667641 blocked by that.

+1 to filing a crbug and doing it later, I agree that it's low priority.

It is strange, but it does work OK for now. This way, we don't have to embed or
run over a 2KB+ image in the tests, and since Blink currently only cares if the
response is decodable even if the response range doesn't correspond to the
requested range, so it works fine.

Also, for this test in particular, the strange 3-byte range response is along
the lines of what a misbehaving server might return, which is one of the reasons
that the full image is loaded when an error occurs.

[commit-bot: I haz the power, 2017-02-08 01:03:46]

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

[commit-bot: I haz the power, 2017-02-08 01:03:47]

Dry run: This issue passed the CQ dry run.

[yhirano, 2017-02-08 01:18:39]

lgtm

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
(right):

https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1215:
TEST(ImageResourceTest, FetchAllowPlaceholderPartialContentWithoutDimensions) {
On 2017/02/07 23:53:48, hiroshige wrote:
> On 2017/02/07 09:24:02, yhirano wrote:
> > The server sends a response consisting of 3 bytes for a request requesting
> > 0-2047 bytes, and it sends a response consisting of 300+ bytes for a request
> for
> > the same URL without a range header. Isn't this behavior strange?
> 
> Yes, strange, but in some of the other unit tests the server responds with
> partial response of ~300 bytes for "bytes=0-2047" range requests (see
> ReloadIfLoFiOrPlaceholderForPlaceholder, or the other uses of
> kJpegImageSubrangeWithDimensionsLength).
> How about filing a crbug and doing it later, as I feel it has lower priority
and
> doesn't affect Issue 667641 directly?
> sclittle@, any thoughts?
> 
> To make this test consistent, we have to create a JPEG file with >2K that
> doesn't contain image dimension information in the first 2KB, and make the
> server to serve the first 2KB of that file for the first request, and serve
the
> whole file for the second request.
> (I know there exists such a JPEG file but haven't constructed one yet)
> Creating such a strange JPEG and testing it might be worth doing (valid but
> extreme cases might be more likely to expose bugs!), but I don't want to have
> Issue 667641 blocked by that.

Please put some comments.

[hiroshige, 2017-02-08 01:20:36]

On 2017/02/08 00:32:59, sclittle wrote:
>
https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
> (right):
> 
>
https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1215:
> TEST(ImageResourceTest, FetchAllowPlaceholderPartialContentWithoutDimensions)
{
> On 2017/02/07 23:53:48, hiroshige wrote:
> > On 2017/02/07 09:24:02, yhirano wrote:
> > > The server sends a response consisting of 3 bytes for a request requesting
> > > 0-2047 bytes, and it sends a response consisting of 300+ bytes for a
request
> > for
> > > the same URL without a range header. Isn't this behavior strange?
> > 
> > Yes, strange, but in some of the other unit tests the server responds with
> > partial response of ~300 bytes for "bytes=0-2047" range requests (see
> > ReloadIfLoFiOrPlaceholderForPlaceholder, or the other uses of
> > kJpegImageSubrangeWithDimensionsLength).
> > How about filing a crbug and doing it later, as I feel it has lower priority
> and
> > doesn't affect Issue 667641 directly?
> > sclittle@, any thoughts?
> > 
> > To make this test consistent, we have to create a JPEG file with >2K that
> > doesn't contain image dimension information in the first 2KB, and make the
> > server to serve the first 2KB of that file for the first request, and serve
> the
> > whole file for the second request.
> > (I know there exists such a JPEG file but haven't constructed one yet)
> > Creating such a strange JPEG and testing it might be worth doing (valid but
> > extreme cases might be more likely to expose bugs!), but I don't want to
have
> > Issue 667641 blocked by that.
> 
> +1 to filing a crbug and doing it later, I agree that it's low priority.
> 
> It is strange, but it does work OK for now. This way, we don't have to embed
or
> run over a 2KB+ image in the tests, and since Blink currently only cares if
the
> response is decodable even if the response range doesn't correspond to the
> requested range, so it works fine.
> 
> Also, for this test in particular, the strange 3-byte range response is along
> the lines of what a misbehaving server might return, which is one of the
reasons
> that the full image is loaded when an error occurs.

Filed crbug.com/689760.

[hiroshige, 2017-02-10 21:06:55]

The CQ bit was checked by hiroshige@chromium.org

[hiroshige, 2017-02-10 21:06:55]

The patchset sent to the CQ was uploaded after l-g-t-m from
sclittle@chromium.org, yhirano@chromium.org
Link to the patchset: https://codereview.chromium.org/2648073002/#ps180001
(title: "add Comments")

[hiroshige, 2017-02-10 21:07:08]

On 2017/02/08 01:20:36, hiroshige wrote:
> On 2017/02/08 00:32:59, sclittle wrote:
> >
>
https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
> > File third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
> > (right):
> > 
> >
>
https://codereview.chromium.org/2648073002/diff/140001/third_party/WebKit/Sou...
> > third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp:1215:
> > TEST(ImageResourceTest,
FetchAllowPlaceholderPartialContentWithoutDimensions)
> {
> > On 2017/02/07 23:53:48, hiroshige wrote:
> > > On 2017/02/07 09:24:02, yhirano wrote:
> > > > The server sends a response consisting of 3 bytes for a request
requesting
> > > > 0-2047 bytes, and it sends a response consisting of 300+ bytes for a
> request
> > > for
> > > > the same URL without a range header. Isn't this behavior strange?
> > > 
> > > Yes, strange, but in some of the other unit tests the server responds with
> > > partial response of ~300 bytes for "bytes=0-2047" range requests (see
> > > ReloadIfLoFiOrPlaceholderForPlaceholder, or the other uses of
> > > kJpegImageSubrangeWithDimensionsLength).
> > > How about filing a crbug and doing it later, as I feel it has lower
priority
> > and
> > > doesn't affect Issue 667641 directly?
> > > sclittle@, any thoughts?
> > > 
> > > To make this test consistent, we have to create a JPEG file with >2K that
> > > doesn't contain image dimension information in the first 2KB, and make the
> > > server to serve the first 2KB of that file for the first request, and
serve
> > the
> > > whole file for the second request.
> > > (I know there exists such a JPEG file but haven't constructed one yet)
> > > Creating such a strange JPEG and testing it might be worth doing (valid
but
> > > extreme cases might be more likely to expose bugs!), but I don't want to
> have
> > > Issue 667641 blocked by that.
> > 
> > +1 to filing a crbug and doing it later, I agree that it's low priority.
> > 
> > It is strange, but it does work OK for now. This way, we don't have to embed
> or
> > run over a 2KB+ image in the tests, and since Blink currently only cares if
> the
> > response is decodable even if the response range doesn't correspond to the
> > requested range, so it works fine.
> > 
> > Also, for this test in particular, the strange 3-byte range response is
along
> > the lines of what a misbehaving server might return, which is one of the
> reasons
> > that the full image is loaded when an error occurs.
> 
> Filed crbug.com/689760.

Added a TODO comment.

[commit-bot: I haz the power, 2017-02-10 21:07:28]

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, 2017-02-10 21:23:22]

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

[commit-bot: I haz the power, 2017-02-10 21:23:23]

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

[hiroshige, 2017-02-10 22:05:56]

The CQ bit was checked by hiroshige@chromium.org

[hiroshige, 2017-02-10 22:05:56]

The patchset sent to the CQ was uploaded after l-g-t-m from
yhirano@chromium.org, sclittle@chromium.org
Link to the patchset: https://codereview.chromium.org/2648073002/#ps200001
(title: "Rebase fix")

[commit-bot: I haz the power, 2017-02-10 22:06:21]

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, 2017-02-10 23:09:04]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1486764356253440,
"parent_rev": "860c070a0b9a6398fa8669b6f1c0c047108d08c5", "commit_rev":
"6d03fad48660f6a6a767c6cc70c621ff10f8fcfa"}

[commit-bot: I haz the power, 2017-02-10 23:09:44]

Description was changed from

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

ImageResourceTest.PartialContentWithoutDimensions
tests that DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests the case where DecodeError with non-empty body in
ResourceLoader::didFinishLoading() causes reloading.

BUG=667641, 677188
==========

to

==========
Add unit tests for placeholder reloading on didFinishLoading

ImageResourceTest.ReloadIfLoFiOrPlaceholderViaResourceFetcher
tests reloading in ResourceFetcher::reloadLoFiImages().

ImageResourceTest.PartialContentWithoutDimensions
tests that DecodeError with non-empty body in
ResourceLoader::didFinishLoading().

ImageResourceTest.FetchAllowPlaceholderPartialContentWithoutDimensions
tests the case where DecodeError with non-empty body in
ResourceLoader::didFinishLoading() causes reloading.

BUG=667641, 677188

Review-Url: https://codereview.chromium.org/2648073002
Cr-Commit-Position: refs/heads/master@{#449776}
Committed:
https://chromium.googlesource.com/chromium/src/+/6d03fad48660f6a6a767c6cc70c6...
==========

[commit-bot: I haz the power, 2017-02-10 23:09:45]

Committed patchset #11 (id:200001) as
https://chromium.googlesource.com/chromium/src/+/6d03fad48660f6a6a767c6cc70c6...