Move iOS ImageFetcher to ios/web/public

Move iOS ImageFetcher to ios/web/public

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to ios/web/public, in order to be able to use it from ios/web and ios/chrome.

BUG=667747
Committed: https://crrev.com/03a0e8dd06380453b181d345f85422314fb0522b
Cr-Commit-Position: refs/heads/master@{#435892}

[gambard, 2016-11-23 13:56:27]

gambard@chromium.org changed reviewers:
+ sdefresne@chromium.org

[gambard, 2016-11-23 13:56:28]

PTAL.
Replace https://codereview.chromium.org/2521253002

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/BUILD.gn (left):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/BUILD.gn:28: libs = [ "CoreGraphics.framework" ]
Do I need this? It seems to be working without it.

[sdefresne, 2016-11-23 14:40:32]

sdefresne@chromium.org changed reviewers:
+ droger@chromium.org

[sdefresne, 2016-11-23 14:40:33]

droger: can you answer my question about deps?

gambard: I think you can remove the dep on //ios/web either way as it is unused
AFAICT.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/BUILD.gn (left):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/BUILD.gn:28: libs = [ "CoreGraphics.framework" ]
On 2016/11/23 13:56:27, gambard wrote:
> Do I need this? It seems to be working without it.

Yes, you need it because webp_decoder_unittest.mm import
CoreGraphics/CoreGraphics.h and uses some of the code from the framework. It
appears to work because this is only required for linking the final application
(it add "-framework CoreGraphics" on the linker command-line) and if any other
target list this framework in its libs then the linker will be happy (since it
only cares about seeing the argument once).

It is better to list it because it makes the target easier to re-use
independently of any other.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/BUILD.gn (right):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/BUILD.gn:14: "//ios/web",
I think you can remove this dependency as you do not use anything from //ios/web
(include is stale AFAICT).

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/DEPS (right):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/DEPS:2: "+ios/web/public",
David: IIRC, this target was explicitly not linking against ios/web/public so
that it could be reused by gsalib/crnet. Do you remember if this is something we
dropped? Or should we still try to have this target dependencies be as small as
possible?

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/raw_image_fetcher.mm (right):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/raw_image_fetcher.mm:15: #include
"ios/web/public/web_thread.h"
Remove.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/raw_image_fetcher.mm:132:
original_url.SchemeIs("data") ? 200 : fetcher->GetResponseCode();
Please use url::kDataScheme instead of "data".

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
File ios/chrome/browser/suggestions/image_fetcher_impl.h (right):

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
ios/chrome/browser/suggestions/image_fetcher_impl.h:55:
std::unique_ptr<image_fetcher::RawImageFetcher> imageFetcher_;
style: This is c++ so this should use_cpp_naming_convention_!

  std::unique_ptr<image_fetcher::RawImageFetcher> image_fetcher_;

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
File ios/chrome/browser/suggestions/image_fetcher_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
ios/chrome/browser/suggestions/image_fetcher_impl.mm:21: imageFetcher_.reset(new
image_fetcher::RawImageFetcher(blocking_pool));
Can you use base::MakeUnique<> here?

ImageFetcherImpl::ImageFetcherImpl(
    net::URLRequestContextGetter* url_request_context,
    base::SequencedWorkerPool* blocking_pool)
    : imageFetcher_(
          base::MakeUnique<image_fetcher::RawImageFetcher>(blocking_pool)) {

[gambard, 2016-11-23 15:01:21]

Thanks!

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/BUILD.gn (left):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/BUILD.gn:28: libs = [ "CoreGraphics.framework" ]
On 2016/11/23 14:40:33, sdefresne wrote:
> On 2016/11/23 13:56:27, gambard wrote:
> > Do I need this? It seems to be working without it.
> 
> Yes, you need it because webp_decoder_unittest.mm import
> CoreGraphics/CoreGraphics.h and uses some of the code from the framework. It
> appears to work because this is only required for linking the final
application
> (it add "-framework CoreGraphics" on the linker command-line) and if any other
> target list this framework in its libs then the linker will be happy (since it
> only cares about seeing the argument once).
> 
> It is better to list it because it makes the target easier to re-use
> independently of any other.

Thanks!
Done.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/BUILD.gn (right):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/BUILD.gn:14: "//ios/web",
On 2016/11/23 14:40:33, sdefresne wrote:
> I think you can remove this dependency as you do not use anything from
//ios/web
> (include is stale AFAICT).

Done.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/DEPS (right):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/DEPS:2: "+ios/web/public",
On 2016/11/23 14:40:33, sdefresne wrote:
> David: IIRC, this target was explicitly not linking against ios/web/public so
> that it could be reused by gsalib/crnet. Do you remember if this is something
we
> dropped? Or should we still try to have this target dependencies be as small
as
> possible?

I removed it.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
File components/image_fetcher/ios/raw_image_fetcher.mm (right):

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/raw_image_fetcher.mm:15: #include
"ios/web/public/web_thread.h"
On 2016/11/23 14:40:33, sdefresne wrote:
> Remove.

Done.

https://codereview.chromium.org/2526773002/diff/1/components/image_fetcher/io...
components/image_fetcher/ios/raw_image_fetcher.mm:132:
original_url.SchemeIs("data") ? 200 : fetcher->GetResponseCode();
On 2016/11/23 14:40:33, sdefresne wrote:
> Please use url::kDataScheme instead of "data".

Done.

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
File ios/chrome/browser/suggestions/image_fetcher_impl.h (right):

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
ios/chrome/browser/suggestions/image_fetcher_impl.h:55:
std::unique_ptr<image_fetcher::RawImageFetcher> imageFetcher_;
On 2016/11/23 14:40:33, sdefresne wrote:
> style: This is c++ so this should use_cpp_naming_convention_!
> 
>   std::unique_ptr<image_fetcher::RawImageFetcher> image_fetcher_;

Done.

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
File ios/chrome/browser/suggestions/image_fetcher_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/1/ios/chrome/browser/suggesti...
ios/chrome/browser/suggestions/image_fetcher_impl.mm:21: imageFetcher_.reset(new
image_fetcher::RawImageFetcher(blocking_pool));
On 2016/11/23 14:40:33, sdefresne wrote:
> Can you use base::MakeUnique<> here?
> 
> ImageFetcherImpl::ImageFetcherImpl(
>     net::URLRequestContextGetter* url_request_context,
>     base::SequencedWorkerPool* blocking_pool)
>     : imageFetcher_(
>           base::MakeUnique<image_fetcher::RawImageFetcher>(blocking_pool)) {

Done.

[gambard, 2016-11-25 07:27:16]

Description was changed from

==========
Move iOS ImageFetcher to components

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to components, in order to be able to use it from outside ios/.

BUG=667747
==========

to

==========
Move iOS ImageFetcher to ios/web/public

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to ios/web/public, in order to be able to use it from ios/web and
ios/chrome.

BUG=667747
==========

[gambard, 2016-11-25 09:11:12]

PTAL.

https://codereview.chromium.org/2526773002/diff/60001/ios/web/BUILD.gn
File ios/web/BUILD.gn (right):

https://codereview.chromium.org/2526773002/diff/60001/ios/web/BUILD.gn#newcod...
ios/web/BUILD.gn:481: "//ios/web/public/image_fetcher:unit_tests",
Not sure if I should put this here or in run_all_unittests...

[sdefresne, 2016-11-25 09:27:51]

lgtm

https://codereview.chromium.org/2526773002/diff/60001/ios/chrome/browser/sugg...
File ios/chrome/browser/suggestions/image_fetcher_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/60001/ios/chrome/browser/sugg...
ios/chrome/browser/suggestions/image_fetcher_impl.mm:64: if (delegate_) {
This is a block that keep a pointer to a C++ object (via "delegate_" which is a
member variable of "this", so it keep a reference to "this"). This is usually
really dangerous as the C++ object may be destroyed before the block is invoked.
Especially troubling here since StartDownload is obviously an asynchronous API.

After looking at RawImageFetcher, I see that the request is cancelled if the
object is destroyed, so this is probably okay. Can you add a comment above this
block so that reviewers don't have to go spelunking every time they review this
code?

https://codereview.chromium.org/2526773002/diff/60001/ios/web/BUILD.gn
File ios/web/BUILD.gn (right):

https://codereview.chromium.org/2526773002/diff/60001/ios/web/BUILD.gn#newcod...
ios/web/BUILD.gn:481: "//ios/web/public/image_fetcher:unit_tests",
On 2016/11/25 09:11:12, gambard wrote:
> Not sure if I should put this here or in run_all_unittests...

You must not put it in run_all_unittests.

[gambard, 2016-11-25 13:24:26]

gambard@chromium.org changed reviewers:
+ eugenebut@chromium.org, urvang@chromium.org

[gambard, 2016-11-25 13:24:27]

Thanks sdefresne@.
eugenebut@: PTAL
urvang@: PTAL for DEPS includes of third_party/libwebp/webp/decode.h

https://codereview.chromium.org/2526773002/diff/60001/ios/chrome/browser/sugg...
File ios/chrome/browser/suggestions/image_fetcher_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/60001/ios/chrome/browser/sugg...
ios/chrome/browser/suggestions/image_fetcher_impl.mm:64: if (delegate_) {
On 2016/11/25 09:27:50, sdefresne wrote:
> This is a block that keep a pointer to a C++ object (via "delegate_" which is
a
> member variable of "this", so it keep a reference to "this"). This is usually
> really dangerous as the C++ object may be destroyed before the block is
invoked.
> Especially troubling here since StartDownload is obviously an asynchronous
API.
> 
> After looking at RawImageFetcher, I see that the request is cancelled if the
> object is destroyed, so this is probably okay. Can you add a comment above
this
> block so that reviewers don't have to go spelunking every time they review
this
> code?

Thanks, done.

[urvang, 2016-11-28 19:51:21]

Not sure what DEPS includes you wanted me to review. Did not see any diff at:
https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...

On 2016/11/25 13:24:27, gambard wrote:
> Thanks sdefresne@.
> eugenebut@: PTAL
> urvang@: PTAL for DEPS includes of third_party/libwebp/webp/decode.h
>

[gambard, 2016-11-29 07:47:45]

On 2016/11/28 19:51:21, urvang wrote:
> Not sure what DEPS includes you wanted me to review. Did not see any diff at:
>
https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
> 
> On 2016/11/25 13:24:27, gambard wrote:
> > Thanks sdefresne@.
> > eugenebut@: PTAL
> > urvang@: PTAL for DEPS includes of third_party/libwebp/webp/decode.h
> >

Yes, I am just moving code (that is why the DEPS is showing up in the list of
files). It is indeed
https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe....

[urvang, 2016-11-29 17:48:45]

On 2016/11/29 07:47:45, gambard wrote:
> On 2016/11/28 19:51:21, urvang wrote:
> > Not sure what DEPS includes you wanted me to review. Did not see any diff
at:
> >
>
https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
> > 
> > On 2016/11/25 13:24:27, gambard wrote:
> > > Thanks sdefresne@.
> > > eugenebut@: PTAL
> > > urvang@: PTAL for DEPS includes of third_party/libwebp/webp/decode.h
> > >
> 
> Yes, I am just moving code (that is why the DEPS is showing up in the list of
> files). It is indeed
>
https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe....

Ah, it was moved from "ios/chrome/browser/webp_transcode/DEPS", got it.
LGTM for that.

[Eugene But (OOO till 7-30), 2016-11-30 17:28:54]

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
File ios/web/public/image_fetcher/mock_raw_image_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/mock_raw_image_fetcher.h:4: 
Please move this to ios/web/public/test.

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/mock_raw_image_fetcher.h:14: // Mock the
RawImageFetcher utility class, which can be used to asynchronously
nit: s/Mock/Mocks

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
File ios/web/public/image_fetcher/raw_image_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/raw_image_fetcher.h:42: class RawImageFetcher :
public net::URLFetcherDelegate {
Should this be ImageDataFetcher?

[blundell, 2016-11-30 20:03:59]

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

[blundell, 2016-11-30 20:04:00]

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
File ios/web/public/image_fetcher/raw_image_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/raw_image_fetcher.h:42: class RawImageFetcher :
public net::URLFetcherDelegate {
On 2016/11/30 17:28:53, Eugene But wrote:
> Should this be ImageDataFetcher?

Now that I'm looking at this, what's the reason the API cutpoint is what it is?
i.e., why doesn't this class return UIImages? Are there use cases where the
NSData gets stored or passed around or something where a UIImage would be
problematic?

This question is outside the scope of this CL. For this CL I would be fine with
ImageDataFetcher (or even ImageBytesFetcher?) if "raw image" has a specific
other meaning that would be likely to cause misinterpretation here.

[gambard, 2016-12-01 09:25:13]

Thanks, PTAL.

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
File ios/web/public/image_fetcher/mock_raw_image_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/mock_raw_image_fetcher.h:4: 
On 2016/11/30 17:28:53, Eugene But wrote:
> Please move this to ios/web/public/test.

Done.

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/mock_raw_image_fetcher.h:14: // Mock the
RawImageFetcher utility class, which can be used to asynchronously
On 2016/11/30 17:28:53, Eugene But wrote:
> nit: s/Mock/Mocks

Done.

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
File ios/web/public/image_fetcher/raw_image_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/raw_image_fetcher.h:42: class RawImageFetcher :
public net::URLFetcherDelegate {
On 2016/11/30 17:28:53, Eugene But wrote:
> Should this be ImageDataFetcher?

Done.

https://codereview.chromium.org/2526773002/diff/80001/ios/web/public/image_fe...
ios/web/public/image_fetcher/raw_image_fetcher.h:42: class RawImageFetcher :
public net::URLFetcherDelegate {
On 2016/11/30 20:04:00, blundell wrote:
> On 2016/11/30 17:28:53, Eugene But wrote:
> > Should this be ImageDataFetcher?
> 
> Now that I'm looking at this, what's the reason the API cutpoint is what it
is?
> i.e., why doesn't this class return UIImages? Are there use cases where the
> NSData gets stored or passed around or something where a UIImage would be
> problematic?
> 
> This question is outside the scope of this CL. For this CL I would be fine
with
> ImageDataFetcher (or even ImageBytesFetcher?) if "raw image" has a specific
> other meaning that would be likely to cause misinterpretation here.

UIImage makes some assumptions about the format/scale of the image. For example
if you download a file favicon.ico containing multiple images, a UIImage
representation will keep only one of them (from my understanding).

[Eugene But (OOO till 7-30), 2016-12-01 16:52:01]

lgtm

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
File ios/chrome/browser/suggestions/image_fetcher_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
ios/chrome/browser/suggestions/image_fetcher_impl.mm:12: #include
"ios/web/public/image_fetcher/image_data_fetcher.h"
s/include/import

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
File ios/chrome/browser/suggestions/ios_image_decoder_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
ios/chrome/browser/suggestions/ios_image_decoder_impl.mm:14: #include
"ios/web/public/image_fetcher/webp_decoder.h"
s/include/import

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/image_f...
File ios/web/public/image_fetcher/image_data_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/image_f...
ios/web/public/image_fetcher/image_data_fetcher.h:5: #ifndef
IOS_WEB_PUBLIC_IMAGE_FETCHER_RAW_IMAGE_FETCHER_H_
IOS_WEB_PUBLIC_IMAGE_FETCHER_IMAGE_DATA_FETCHER_H_

FYI: tools/git/move_source_file.py tool takes care about renaming include guards

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/test/mo...
File ios/web/public/test/mock_image_data_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/test/mo...
ios/web/public/test/mock_image_data_fetcher.h:5: #ifndef
IOS_WEB_PUBLIC_IMAGE_FETCHER_MOCK_RAW_IMAGE_FETCHER_H_
IOS_WEB_PUBLIC_TEST_MOCK_IMAGE_DATA_FETCHER_H_

[gambard, 2016-12-02 08:06:13]

Thanks.

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
File ios/chrome/browser/suggestions/image_fetcher_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
ios/chrome/browser/suggestions/image_fetcher_impl.mm:12: #include
"ios/web/public/image_fetcher/image_data_fetcher.h"
On 2016/12/01 16:52:01, Eugene But wrote:
> s/include/import

Done.

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
File ios/chrome/browser/suggestions/ios_image_decoder_impl.mm (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/chrome/browser/sug...
ios/chrome/browser/suggestions/ios_image_decoder_impl.mm:14: #include
"ios/web/public/image_fetcher/webp_decoder.h"
On 2016/12/01 16:52:01, Eugene But wrote:
> s/include/import

Done.

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/image_f...
File ios/web/public/image_fetcher/image_data_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/image_f...
ios/web/public/image_fetcher/image_data_fetcher.h:5: #ifndef
IOS_WEB_PUBLIC_IMAGE_FETCHER_RAW_IMAGE_FETCHER_H_
On 2016/12/01 16:52:01, Eugene But wrote:
> IOS_WEB_PUBLIC_IMAGE_FETCHER_IMAGE_DATA_FETCHER_H_
> 
> FYI: tools/git/move_source_file.py tool takes care about renaming include
guards

Done.

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/test/mo...
File ios/web/public/test/mock_image_data_fetcher.h (right):

https://codereview.chromium.org/2526773002/diff/100001/ios/web/public/test/mo...
ios/web/public/test/mock_image_data_fetcher.h:5: #ifndef
IOS_WEB_PUBLIC_IMAGE_FETCHER_MOCK_RAW_IMAGE_FETCHER_H_
On 2016/12/01 16:52:01, Eugene But wrote:
> IOS_WEB_PUBLIC_TEST_MOCK_IMAGE_DATA_FETCHER_H_

Done.

[gambard, 2016-12-02 08:06:19]

The CQ bit was checked by gambard@chromium.org

[gambard, 2016-12-02 08:06:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
sdefresne@chromium.org, urvang@chromium.org, eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/2526773002/#ps120001
(title: "Rename headers")

[commit-bot: I haz the power, 2016-12-02 08:06:38]

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-12-02 09:11:09]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1480665979811010,
"parent_rev": "2bd6be8f48f6c4dab4ad6bfe1bbdfcc5b5c1f0a8", "commit_rev":
"8c5b981efa5daa26fd2406651df26c8407cfcc24"}

[commit-bot: I haz the power, 2016-12-02 09:11:40]

Description was changed from

==========
Move iOS ImageFetcher to ios/web/public

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to ios/web/public, in order to be able to use it from ios/web and
ios/chrome.

BUG=667747
==========

to

==========
Move iOS ImageFetcher to ios/web/public

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to ios/web/public, in order to be able to use it from ios/web and
ios/chrome.

BUG=667747
==========

[commit-bot: I haz the power, 2016-12-02 09:11:41]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-12-02 09:15:15]

Description was changed from

==========
Move iOS ImageFetcher to ios/web/public

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to ios/web/public, in order to be able to use it from ios/web and
ios/chrome.

BUG=667747
==========

to

==========
Move iOS ImageFetcher to ios/web/public

This CL moves and renames the RawImageFetcher getting the data from the url.
It moves it to ios/web/public, in order to be able to use it from ios/web and
ios/chrome.

BUG=667747

Committed: https://crrev.com/03a0e8dd06380453b181d345f85422314fb0522b
Cr-Commit-Position: refs/heads/master@{#435892}
==========

[commit-bot: I haz the power, 2016-12-02 09:15:16]

Patchset 7 (id:??) landed as
https://crrev.com/03a0e8dd06380453b181d345f85422314fb0522b
Cr-Commit-Position: refs/heads/master@{#435892}