Allow webRequest API extension to clear the in-memory cache of WebKit.

Allow webRequest API extensions to clear the in-memory cache of WebKit.

If the behavior of a webRequest API extension changes (i.e. different URLs are blocked) this effect was not visible instantly due to WebKit's in-memory cache. This CL introduces a means to clear the cache.

BUG=94284
TEST=no


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=103289

[battre, 2011-09-07 15:24:04]

This is a minimal CL that fixes 94284 (I was able to reproduce the issue and
observe that is was fixed with this CL).

Instead of doing something fancy like clearing the cache only on a reload, it
does the clearing instantly. I suppose clearing the cache on reload is a
performance optimization but I am neither sure whether it is necessary in the
long-run nor crucial for the first release of this API. 

If you think we should allow the clearing on reload, I'd be appreciate to put it
onto my todo-list until we have addressed the crucial parts of the API that
affect stability and feature completeness.

WDYT?

http://codereview.chromium.org/7835031/diff/1/chrome/browser/extensions/exten...
File chrome/browser/extensions/extension_webrequest_api.h (right):

http://codereview.chromium.org/7835031/diff/1/chrome/browser/extensions/exten...
chrome/browser/extensions/extension_webrequest_api.h:377:
"experimental.webRequest.handlerBehaviorChanged");
I am not sure whether this is a good name. "clearInMemoryCaches" would be a
better description of what the function executes. I don't know whether we want
to expose this detail to extension authors. OTOH they might call
handlerBehaviorChanged more often than they need to if we don't tell them what
is going on. WDYT?

[willchan no longer on Chromium, 2011-09-07 17:43:05]

I defer to Matt and Adam here. FWIW, I advise you update the changelist
description to specify the exact cache (the WebKit resource cache or whatever
it's called I presume) is being cleared, since there are lots of caches in
Chrome.

Also, FWIW, IMO, it sounds really damaging to perf to have the extension API
purge all WebKit resource caches =/ I worry about extensions killing Chrome perf
and us not having any visibility into the fact that extensions are doing it.
People will just blame Chrome.

On 2011/09/07 15:24:04, battre wrote:
> This is a minimal CL that fixes 94284 (I was able to reproduce the issue and
> observe that is was fixed with this CL).
> 
> Instead of doing something fancy like clearing the cache only on a reload, it
> does the clearing instantly. I suppose clearing the cache on reload is a
> performance optimization but I am neither sure whether it is necessary in the
> long-run nor crucial for the first release of this API. 
> 
> If you think we should allow the clearing on reload, I'd be appreciate to put
it
> onto my todo-list until we have addressed the crucial parts of the API that
> affect stability and feature completeness.
> 
> WDYT?
> 
>
http://codereview.chromium.org/7835031/diff/1/chrome/browser/extensions/exten...
> File chrome/browser/extensions/extension_webrequest_api.h (right):
> 
>
http://codereview.chromium.org/7835031/diff/1/chrome/browser/extensions/exten...
> chrome/browser/extensions/extension_webrequest_api.h:377:
> "experimental.webRequest.handlerBehaviorChanged");
> I am not sure whether this is a good name. "clearInMemoryCaches" would be a
> better description of what the function executes. I don't know whether we want
> to expose this detail to extension authors. OTOH they might call
> handlerBehaviorChanged more often than they need to if we don't tell them what
> is going on. WDYT?

[abarth-chromium, 2011-09-07 17:54:09]

I worry about the performance impact as well.  Generally we have worked hard to
avoid letting extensions slow down the browser.  One of the reasons Firefox
feels slow is that folks install extensions that bog down perf.

I'm not sure I should be the one making this call though.  This sounds like more
of a question for Mihaip or Erik.

[Matt Perry, 2011-09-08 00:14:33]

I'm conflicted. Erik, WDYT?

On the one hand, Adblock needs something like this, or it will look broken. On
the other, the way we do it is not perfect:
- extensions can easily abuse it and cause massive perf hits.
- it doesn't fully solve the problem. say I only block resources from foo.com
50% of the time. after the first request makes it through, it gets stuck in the
cache, and won't get blocked anymore. i'd have to clear the cache constantly.

On the other other hand, I can't think of a better way to do this, and it's
probably better than nothing...

On 2011/09/07 17:54:09, abarth wrote:
> I worry about the performance impact as well.  Generally we have worked hard
to
> avoid letting extensions slow down the browser.  One of the reasons Firefox
> feels slow is that folks install extensions that bog down perf.
> 
> I'm not sure I should be the one making this call though.  This sounds like
more
> of a question for Mihaip or Erik.

[Mihai Parparita -not on Chrome, 2011-09-08 00:28:18]

Dominic: do you have any sense of how complex the proposed WebKit changes in
http://crbug.com/94284 would be?

Mihai

On Wed, Sep 7, 2011 at 5:14 PM, <[email protected]> wrote:

> I'm conflicted. Erik, WDYT?
>
> On the one hand, Adblock needs something like this, or it will look broken.
> On
> the other, the way we do it is not perfect:
> - extensions can easily abuse it and cause massive perf hits.
> - it doesn't fully solve the problem. say I only block resources from
> foo.com
> 50% of the time. after the first request makes it through, it gets stuck in
> the
> cache, and won't get blocked anymore. i'd have to clear the cache
> constantly.
>
> On the other other hand, I can't think of a better way to do this, and it's
> probably better than nothing...
>
> On 2011/09/07 17:54:09, abarth wrote:
>
>> I worry about the performance impact as well.  Generally we have worked
>> hard
>>
> to
>
>> avoid letting extensions slow down the browser.  One of the reasons
>> Firefox
>> feels slow is that folks install extensions that bog down perf.
>>
>
>  I'm not sure I should be the one making this call though.  This sounds
>> like
>>
> more
>
>> of a question for Mihaip or Erik.
>>
>
>
>
http://codereview.chromium.**org/7835031/<http://codereview.chromium.org/7835...
>

[battre, 2011-09-08 08:20:08]

Not really, but it should be doable. For large parts it is just replicating
functionality WebCacheManager. I will have to see how I can capture a reload and
communicate this to the MemoryCache. I am not familiar enough with WebKit to
estimate the difficulty.

On 2011/09/08 00:28:18, Mihai Parparita wrote:
> Dominic: do you have any sense of how complex the proposed WebKit changes in
> http://crbug.com/94284 would be?
> 
> Mihai
> 
> On Wed, Sep 7, 2011 at 5:14 PM, <mailto:[email protected]> wrote:
> 
> > I'm conflicted. Erik, WDYT?
> >
> > On the one hand, Adblock needs something like this, or it will look broken.
> > On
> > the other, the way we do it is not perfect:
> > - extensions can easily abuse it and cause massive perf hits.
> > - it doesn't fully solve the problem. say I only block resources from
> > http://foo.com
> > 50% of the time. after the first request makes it through, it gets stuck in
> > the
> > cache, and won't get blocked anymore. i'd have to clear the cache
> > constantly.
> >
> > On the other other hand, I can't think of a better way to do this, and it's
> > probably better than nothing...
> >
> > On 2011/09/07 17:54:09, abarth wrote:
> >
> >> I worry about the performance impact as well.  Generally we have worked
> >> hard
> >>
> > to
> >
> >> avoid letting extensions slow down the browser.  One of the reasons
> >> Firefox
> >> feels slow is that folks install extensions that bog down perf.
> >>
> >
> >  I'm not sure I should be the one making this call though.  This sounds
> >> like
> >>
> > more
> >
> >> of a question for Mihaip or Erik.
> >>
> >
> >
> >
>
http://codereview.chromium.**org/7835031/%3Chttp://codereview.chromium.org/78...>
> >

[battre, 2011-09-15 12:16:34]

I have updated this CL to allow clearing the cache upon reloading. The changes
were pretty simple. Please take a look.

On 2011/09/08 00:28:18, Mihai Parparita wrote:
> Dominic: do you have any sense of how complex the proposed WebKit changes in
> http://crbug.com/94284 would be?
> 
> Mihai
> 
> On Wed, Sep 7, 2011 at 5:14 PM, <mailto:[email protected]> wrote:
> 
> > I'm conflicted. Erik, WDYT?
> >
> > On the one hand, Adblock needs something like this, or it will look broken.
> > On
> > the other, the way we do it is not perfect:
> > - extensions can easily abuse it and cause massive perf hits.
> > - it doesn't fully solve the problem. say I only block resources from
> > http://foo.com
> > 50% of the time. after the first request makes it through, it gets stuck in
> > the
> > cache, and won't get blocked anymore. i'd have to clear the cache
> > constantly.
> >
> > On the other other hand, I can't think of a better way to do this, and it's
> > probably better than nothing...
> >
> > On 2011/09/07 17:54:09, abarth wrote:
> >
> >> I worry about the performance impact as well.  Generally we have worked
> >> hard
> >>
> > to
> >
> >> avoid letting extensions slow down the browser.  One of the reasons
> >> Firefox
> >> feels slow is that folks install extensions that bog down perf.
> >>
> >
> >  I'm not sure I should be the one making this call though.  This sounds
> >> like
> >>
> > more
> >
> >> of a question for Mihaip or Erik.
> >>
> >
> >
> >
>
http://codereview.chromium.**org/7835031/%3Chttp://codereview.chromium.org/78...>
> >

[battre, 2011-09-15 12:57:13]

Ok, the trybots fail because this depends on
https://bugs.webkit.org/show_bug.cgi?id=68154

On 2011/09/15 12:16:34, battre wrote:
> I have updated this CL to allow clearing the cache upon reloading. The changes
> were pretty simple. Please take a look.
> 
> On 2011/09/08 00:28:18, Mihai Parparita wrote:
> > Dominic: do you have any sense of how complex the proposed WebKit changes in
> > http://crbug.com/94284 would be?
> > 
> > Mihai
> > 
> > On Wed, Sep 7, 2011 at 5:14 PM, <mailto:[email protected]> wrote:
> > 
> > > I'm conflicted. Erik, WDYT?
> > >
> > > On the one hand, Adblock needs something like this, or it will look
broken.
> > > On
> > > the other, the way we do it is not perfect:
> > > - extensions can easily abuse it and cause massive perf hits.
> > > - it doesn't fully solve the problem. say I only block resources from
> > > http://foo.com
> > > 50% of the time. after the first request makes it through, it gets stuck
in
> > > the
> > > cache, and won't get blocked anymore. i'd have to clear the cache
> > > constantly.
> > >
> > > On the other other hand, I can't think of a better way to do this, and
it's
> > > probably better than nothing...
> > >
> > > On 2011/09/07 17:54:09, abarth wrote:
> > >
> > >> I worry about the performance impact as well.  Generally we have worked
> > >> hard
> > >>
> > > to
> > >
> > >> avoid letting extensions slow down the browser.  One of the reasons
> > >> Firefox
> > >> feels slow is that folks install extensions that bog down perf.
> > >>
> > >
> > >  I'm not sure I should be the one making this call though.  This sounds
> > >> like
> > >>
> > > more
> > >
> > >> of a question for Mihaip or Erik.
> > >>
> > >
> > >
> > >
> >
>
http://codereview.chromium.**org/7835031/%253Chttp://codereview.chromium.org/...>
> > >

[Matt Perry, 2011-09-15 18:08:14]

I'm happy with this compromise. LGTM

http://codereview.chromium.org/7835031/diff/7001/chrome/browser/renderer_host...
File chrome/browser/renderer_host/web_cache_manager.h (right):

http://codereview.chromium.org/7835031/diff/7001/chrome/browser/renderer_host...
chrome/browser/renderer_host/web_cache_manager.h:185: enum ClearCacheOccation {
do you mean occasion?

http://codereview.chromium.org/7835031/diff/7001/chrome/renderer/chrome_rende...
File chrome/renderer/chrome_render_process_observer.cc (right):

http://codereview.chromium.org/7835031/diff/7001/chrome/renderer/chrome_rende...
chrome/renderer/chrome_render_process_observer.cc:457: if (on_tab_reload)
nit: chrome style is to always include braces when there's an else branch.

[abarth-chromium, 2011-09-15 18:31:28]

http://codereview.chromium.org/7835031/diff/7001/content/renderer/render_view.cc
File content/renderer/render_view.cc (right):

http://codereview.chromium.org/7835031/diff/7001/content/renderer/render_view...
content/renderer/render_view.cc:773: WebCache::executePendingClear();
So, this only triggers on reload?  Not on normal navigations?

[battre, 2011-09-15 19:27:37]

http://codereview.chromium.org/7835031/diff/7001/content/renderer/render_view.cc
File content/renderer/render_view.cc (right):

http://codereview.chromium.org/7835031/diff/7001/content/renderer/render_view...
content/renderer/render_view.cc:773: WebCache::executePendingClear();
On 2011/09/15 18:31:29, abarth wrote:
> So, this only triggers on reload?  Not on normal navigations?

yes, on second thought, I should change that. Thanks for pointing this out.

[battre, 2011-09-16 12:13:22]

Thanks for your review. I have addressed your comments.

If this is ok with you, please also review
https://bugs.webkit.org/attachment.cgi?id=107635&action=review

Thanks.
Dominic

http://codereview.chromium.org/7835031/diff/7001/chrome/browser/renderer_host...
File chrome/browser/renderer_host/web_cache_manager.h (right):

http://codereview.chromium.org/7835031/diff/7001/chrome/browser/renderer_host...
chrome/browser/renderer_host/web_cache_manager.h:185: enum ClearCacheOccation {
On 2011/09/15 18:08:14, Matt Perry wrote:
> do you mean occasion?

Done.

http://codereview.chromium.org/7835031/diff/7001/chrome/renderer/chrome_rende...
File chrome/renderer/chrome_render_process_observer.cc (right):

http://codereview.chromium.org/7835031/diff/7001/chrome/renderer/chrome_rende...
chrome/renderer/chrome_render_process_observer.cc:457: if (on_tab_reload)
On 2011/09/15 18:08:14, Matt Perry wrote:
> nit: chrome style is to always include braces when there's an else branch.

Done.

http://codereview.chromium.org/7835031/diff/7001/content/renderer/render_view.cc
File content/renderer/render_view.cc (right):

http://codereview.chromium.org/7835031/diff/7001/content/renderer/render_view...
content/renderer/render_view.cc:773: WebCache::executePendingClear();
On 2011/09/15 19:27:38, battre wrote:
> On 2011/09/15 18:31:29, abarth wrote:
> > So, this only triggers on reload?  Not on normal navigations?
> 
> yes, on second thought, I should change that. Thanks for pointing this out.

Done.

[Matt Perry, 2011-09-16 17:55:42]

On 2011/09/16 12:13:22, battre wrote:
> Thanks for your review. I have addressed your comments.
> 
> If this is ok with you, please also review
> https://bugs.webkit.org/attachment.cgi?id=107635&action=review

I'm not a webkit reviewer, so I assume you're talking to Adam?

[abarth-chromium, 2011-09-16 17:58:05]

On Fri, Sep 16, 2011 at 10:55 AM,  <[email protected]> wrote:
> On 2011/09/16 12:13:22, battre wrote:
>>
>> Thanks for your review. I have addressed your comments.
>
>> If this is ok with you, please also review
>> https://bugs.webkit.org/attachment.cgi?id=107635&action=review
>
> I'm not a webkit reviewer, so I assume you're talking to Adam?

We need fishd (aka Darin Fisher) to review that change because it
changes the WebKit API.

[battre, 2011-09-19 17:02:08]

I have moved all code from webkit and content to chrome. Please take another
look.

[Matt Perry, 2011-09-19 19:53:58]

new changes seem OK to me

[battre, 2011-09-27 19:07:51]

This is a friendly ping. Are you happy with the current CL?

Regarding the OWNERS check, Matt's review would be sufficient, but I suppose
that others want to comment on this as well.

[abarth-chromium, 2011-09-27 19:09:53]

On 2011/09/27 19:07:51, battre wrote:
> This is a friendly ping. Are you happy with the current CL?

you = ?

[willchan no longer on Chromium, 2011-09-27 19:10:35]

I think you guys already know, but in case it's not clear, I defer to others
here.

On 2011/09/27 19:07:51, battre wrote:
> This is a friendly ping. Are you happy with the current CL?
> 
> Regarding the OWNERS check, Matt's review would be sufficient, but I suppose
> that others want to comment on this as well.

[battre, 2011-09-27 19:43:03]

On 2011/09/27 19:09:53, abarth wrote:
> On 2011/09/27 19:07:51, battre wrote:
> > This is a friendly ping. Are you happy with the current CL?
> 
> you = ?

Unfortunately, I am not sure who "you" should be. I was hoping from the previous
discussion that you (Adam) and Mihai might have the authority to acknowledge
this, given that the cache flushing seems somewhat controversial.

If you don't feel comfortable, please suggest other reviewers, in case you can.
If you think that Matt's review is sufficient, that would work for me as well.

[abarth-chromium, 2011-09-27 21:10:38]

I'm not particularly excited about this change, but I'm certainly not going to
stand in your way.  In some sense, extensions can already cause performance
problems.  I'm just sad that it will be hard for users to attribute the blame
and exert market pressure on extensions that cause lots of cache misses.

[commit-bot: I haz the power, 2011-09-29 14:54:09]

CQ is trying tha patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/7835031/30001

[commit-bot: I haz the power, 2011-09-29 16:54:35]

Change committed as 103289