Reload favicon from HTTP cache on Ctrl+Refresh

Reload favicon from HTTP cache on Ctrl+Refresh

This CL adds a new parameter to WebContents::DownloadImage() to indicate
whether the request should bypass the cache.

BUG=455383
TEST=FaviconTabHelperTest.ReloadIgnoringCache

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

[pkotwicz, 2015-02-17 04:06:39]

Patchset #1 (id:1) has been deleted

[pkotwicz, 2015-02-19 16:16:14]

[email protected] changed reviewers:
+ [email protected]

[pkotwicz, 2015-02-19 16:16:27]

Patchset #1 (id:20001) has been deleted

[pkotwicz, 2015-02-19 16:47:02]

Scott, can you please take a look? I have included some comments inline with the
code explaining why I am doing things the way I am

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_tab_helper.cc (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper.cc:160: bypass_cache_page_url_ =
GURL();
I used a separate variable to track whether the favicon should be fetched
bypassing the cache. It unlikely but possible for the favicon not to be cached
in the history database but to be cached in the HTTP cache (e.g. open a new
profile, navigate to http://www.google.com/favicon.ico, then navigate to
www.google.com and press Ctrl+F5)

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper.cc:238: bypass_cache_page_url_ = url;
Not sure if I should do this only if |reload_type| is
NavigationController::RELOAD_IGNORING_CACHE

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper.cc:261: // redownloaded.
www.youtube.com calls history.replace() right after being navigated to

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_tab_helper_browsertest.cc (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:29: // the request
bypasses the cache.
This file violates chrome/browser/favicon/DEPS
I suspect an exception is perfectly fine?

I did not find a way of writing this test without making a browser test. In
particular, I need to navigate to a real webpage.

https://codereview.chromium.org/934693002/diff/40001/content/common/image_mes...
File content/common/image_messages.h (right):

https://codereview.chromium.org/934693002/diff/40001/content/common/image_mes...
content/common/image_messages.h:18:
IPC_ENUM_TRAITS(blink::WebURLRequest::CachePolicy);
This is a style violation + DEPS violation.
- I did not want to pass a boolean variable via the IPC
- content/common suggests that I would need to pull the enum into its own file
in order to use it here. Before doing all of that work, I wanted to get sign off
on using this enum (v.s. using a boolean or a different enum)

[sky, 2015-02-19 18:08:11]

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_handler.cc (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_handler.cc:389: DownloadRequest download_request
= i->second;
I'm assuming you didn't make this a const & because you made it so
download_requests_ is cleared below. I don't like clearing download_requests_
for the reasons I mention below, but if you do end up keeping it you should
document here why download_requests is a value. It's subtle.

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_handler.cc:436: // HasPendingDownloadsForTest().
I'm confused. Why do we need to do this? If it's just for a test can't the test
figure out whatever it needs without changing this?

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_handler.cc:449: download_requests_.erase(id);
This is subtle too. |i| may have been invalidated. Again, I don't think you
should be messing with download_requests_ on 437. It makes this function harder
to reason about.

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_handler.cc:616: waiting_for_favicon_service_data_
= true;
Is there a reason you don't want to move setting this to
GetFaviconFromFaviconService and UpdateFaviconMappingAndFetch?

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_handler.h (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_handler.h:116: // For testing. Returns whether
there are any pending FaviconService requests.
This class already has a friend for testing, can you access what you need via
the friend?

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_tab_helper_browsertest.cc (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:1: // Copyright 2014
The Chromium Authors. All rights reserved.
2015

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:29: // the request
bypasses the cache.
On 2015/02/19 16:47:02, pkotwicz wrote:
> This file violates chrome/browser/favicon/DEPS
> I suspect an exception is perfectly fine?

What files doesn't deps like?

> I did not find a way of writing this test without making a browser test. In
> particular, I need to navigate to a real webpage.

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:33: explicit
TestResourceDispatcherHostDelegate(GURL url)
const GURL&

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:77:
ScopedVector<content::ResourceThrottle>* throttles) override {
> 80

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:152: return
FaviconTabHelper::FromWebContents(web_contents())->favicon_handler_.get();
> 80

[pkotwicz, 2015-02-19 21:18:00]

Patchset #2 (id:60001) has been deleted

[pkotwicz, 2015-02-19 21:27:01]

Patchset #2 (id:80001) has been deleted

[pkotwicz, 2015-02-19 21:29:57]

Scott, can you please take another look?

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_handler.h (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_handler.h:116: // For testing. Returns whether
there are any pending FaviconService requests.
Thanks for the suggestion. FaviconHandler now has two friends.

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_tab_helper_browsertest.cc (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:29: // the request
bypasses the cache.
DEPS does not like chrome/browser/ui

https://codereview.chromium.org/934693002/diff/100001/chrome/browser/favicon/...
File chrome/browser/favicon/favicon_handler.cc (right):

https://codereview.chromium.org/934693002/diff/100001/chrome/browser/favicon/...
chrome/browser/favicon/favicon_handler.cc:387: DownloadRequest download_request
= i->second;
I switched to erasing |download_requests_| immediately after copying the value.
I think this makes things clearer.

I am not sure what else I can use to track whether there are pending downloads.
|image_urls_| is cleared when we find the best favicon as a result of
downloading but is not cleared in other cases.

[sky, 2015-02-20 17:57:50]

Everything here looks good. I'll approve after you update DEPS.

Also, I'm not an owner in content, and didn't look at all there. You'll need an
owner for that.

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
File chrome/browser/favicon/favicon_tab_helper_browsertest.cc (right):

https://codereview.chromium.org/934693002/diff/40001/chrome/browser/favicon/f...
chrome/browser/favicon/favicon_tab_helper_browsertest.cc:29: // the request
bypasses the cache.
On 2015/02/19 21:29:57, pkotwicz wrote:
> DEPS does not like chrome/browser/ui

Updating DEPS for the test is fine.

[pkotwicz, 2015-02-20 18:18:36]

jam@ can you please take a look at the changes in content/
Can you especially take a look at the changes in content/common/image_messages.h
In order to use blink::WebURLREquest::CachePolicy in IPC messages, I would need
to pull the enum into its own file according to content/common/DEPS. Before
doing all of that work, I wanted to get sign off
on using this enum (v.s. using a boolean or a different enum)

[pkotwicz, 2015-02-20 18:18:50]

[email protected] changed reviewers:
+ [email protected]

[jam, 2015-02-20 21:34:11]

On 2015/02/20 18:18:36, pkotwicz wrote:
> jam@ can you please take a look at the changes in content/
> Can you especially take a look at the changes in
content/common/image_messages.h
> In order to use blink::WebURLREquest::CachePolicy in IPC messages, I would
need
> to pull the enum into its own file according to content/common/DEPS. Before
> doing all of that work, I wanted to get sign off
> on using this enum (v.s. using a boolean or a different enum)

right, it'd need to be moved out.

btw for *_messages.h files, I'm not an owner. You'd need a security person to
review that.

the other changes in content look fine to me

[jam, 2015-02-20 21:34:12]

On 2015/02/20 18:18:36, pkotwicz wrote:
> jam@ can you please take a look at the changes in content/
> Can you especially take a look at the changes in
content/common/image_messages.h
> In order to use blink::WebURLREquest::CachePolicy in IPC messages, I would
need
> to pull the enum into its own file according to content/common/DEPS. Before
> doing all of that work, I wanted to get sign off
> on using this enum (v.s. using a boolean or a different enum)

right, it'd need to be moved out.

btw for *_messages.h files, I'm not an owner. You'd need a security person to
review that.

the other changes in content look fine to me

[pkotwicz, 2015-02-21 00:17:25]

jam@ who is the best person to advise whether I should pull
blink::WebURLRequest::CachePolicy into a new file or use a different enum, or a
bool? (I doubt a security person would care which enum I pass in the IPC message
as long as I use IPC_ENUM_TRAITS_MAX_VALUE())

[jam, 2015-02-23 15:15:46]

On 2015/02/21 00:17:25, pkotwicz wrote:
> jam@ who is the best person to advise whether I should pull
> blink::WebURLRequest::CachePolicy into a new file or use a different enum, or
a
> bool? (I doubt a security person would care which enum I pass in the IPC
message
> as long as I use IPC_ENUM_TRAITS_MAX_VALUE())

will a bool suffice in your method? if so, i would stick with a bool

[pkotwicz, 2015-02-25 18:57:55]

jam@ can you please take another look?

Yes, a bool would suffice. I have changed the method to take a bool as a
parameter.

[pkotwicz, 2015-02-27 02:37:00]

jam@ ping!

[pkotwicz, 2015-03-03 20:42:29]

jam@ Ping!

[jam, 2015-03-03 21:10:40]

lgtm for content

I'm really sorry I missed your earlier pings. I've been having machine problems
and it's interfering with how I manage pending reviews.

[pkotwicz, 2015-03-03 23:17:12]

Scott, can you please take another look at the chrome/ changes?

I have modified the DEPS file as requested. I have also changed
content::WebContentsImpl::DownloadImage() to take a "bool bypass_cache"
parameter instead of an enum as per jam@'s suggestion. So all of that plumbing
has changed.

[sky, 2015-03-04 15:44:14]

LGTM

[pkotwicz, 2015-03-04 16:04:15]

[email protected] changed reviewers:
+ [email protected]

[pkotwicz, 2015-03-04 16:04:16]

inferno@ can you please take a look at the changes in
content/common/image_messages.h

[pkotwicz, 2015-03-06 03:32:07]

inferno@ Ping!

[pkotwicz, 2015-03-10 21:23:17]

[email protected] changed reviewers:
+ [email protected]

[pkotwicz, 2015-03-10 21:24:58]

tsepez@ can you please take a look at the changes in
content/common/image_messages.h

[Tom Sepez, 2015-03-10 21:44:20]

Messages LGTM

[pkotwicz, 2015-03-15 21:20:07]

The CQ bit was checked by [email protected]

[pkotwicz, 2015-03-15 21:20:08]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected], [email protected]
Link to the patchset: https://codereview.chromium.org/934693002/#ps160001
(title: " ")

[commit-bot: I haz the power, 2015-03-15 21:20:20]

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

[commit-bot: I haz the power, 2015-03-16 00:29:27]

Committed patchset #5 (id:160001)

[commit-bot: I haz the power, 2015-03-16 00:30:23]

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