Blocking resource request for hidden page when interstitial showing

This CL adds a way to block resource requests in the ResourceDispatcherHost for specific RenderViewHosts.
This is used by the interstitial code to prevent the original page from making network requests while the interstitial is showing.

Several UI tests are still required to test this. Because of the inherent complexity of the scenarios to test this, I'm afraid these tests are going to be flakey and soon after disabled (like many of the interstitial UI tests at this point).
This will be done next as part of my next effort to mock some of the WebContents stuff.

TEST=Run the unit tests. Create a page that does XMLHttpRequests and log when the requests complete with the time it did. While that page is shown, switch to a malware/bad SSL page. Come back to the page, ensure no requests were processed while the interstitial was showing.
BUG=None

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

[Paul Godavari, 2009-01-07 00:16:29]

http://codereview.chromium.org/16546/diff/207/208
File chrome/browser/interstitial_page.cc (right):

http://codereview.chromium.org/16546/diff/207/208#newcode20
Line 20: namespace {
Nit: Don't need to indent inside the namespace.

http://codereview.chromium.org/16546/diff/207/208#newcode23
Line 23: enum Action {
Nit: Block is indented 1 space too far.

http://codereview.chromium.org/16546/diff/207/208#newcode29
Line 29: : action_(action),
Nit: Indent by 4 spaces.

http://codereview.chromium.org/16546/diff/207/208#newcode59
Line 59: ResourceDispatcherHost* resource_dispatcher_host_;
DISALLOW_COPY_AND_ASSIGN(ResourceRequestTask);

http://codereview.chromium.org/16546/diff/207/208#newcode66
Line 66: ResourceRequestTask::Action action) {
I think it would be a good idea to DCHECK that we're on the main UI loop at this
point.

http://codereview.chromium.org/16546/diff/207/208#newcode71
Line 71: }
Nit: Blank line, then:
}  // namespace

http://codereview.chromium.org/16546/diff/207/208#newcode234
Line 234: // page and we won't return to the original page, so we cancel bloqued
Nit: 'blocked'

http://codereview.chromium.org/16546/diff/207/211
File chrome/browser/renderer_host/resource_dispatcher_host.cc (right):

http://codereview.chromium.org/16546/diff/207/211#newcode629
Line 629: render_view_ids.insert(iter->first.second);
Might be useful to add a comment here why we don't just call 
CancelBlockedRequestsForRenderView directly.

http://codereview.chromium.org/16546/diff/207/211#newcode1299
Line 1299: delete requests;
Will this clean up will have to be done in the destructor too, or can we rely on
the channel tear down to do it for us?

[jcampan, 2009-01-07 23:56:55]

http://codereview.chromium.org/16546/diff/207/208
File chrome/browser/interstitial_page.cc (right):

http://codereview.chromium.org/16546/diff/207/208#newcode20
Line 20: namespace {
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Nit: Don't need to indent inside the namespace.

Done.

http://codereview.chromium.org/16546/diff/207/208#newcode23
Line 23: enum Action {
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Nit: Block is indented 1 space too far.

Done.

http://codereview.chromium.org/16546/diff/207/208#newcode29
Line 29: : action_(action),
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Nit: Indent by 4 spaces.

Done.

http://codereview.chromium.org/16546/diff/207/208#newcode59
Line 59: ResourceDispatcherHost* resource_dispatcher_host_;
On 2009/01/07 00:16:29, Paul Godavari wrote:
> DISALLOW_COPY_AND_ASSIGN(ResourceRequestTask);

Done.

http://codereview.chromium.org/16546/diff/207/208#newcode66
Line 66: ResourceRequestTask::Action action) {
On 2009/01/07 00:16:29, Paul Godavari wrote:
> I think it would be a good idea to DCHECK that we're on the main UI loop at
this
> point.

Done. I had to make the method non static to get there.

http://codereview.chromium.org/16546/diff/207/208#newcode71
Line 71: }
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Nit: Blank line, then:
> }  // namespace

Done.

http://codereview.chromium.org/16546/diff/207/208#newcode234
Line 234: // page and we won't return to the original page, so we cancel bloqued
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Nit: 'blocked'

Done.

http://codereview.chromium.org/16546/diff/207/211
File chrome/browser/renderer_host/resource_dispatcher_host.cc (right):

http://codereview.chromium.org/16546/diff/207/211#newcode629
Line 629: render_view_ids.insert(iter->first.second);
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Might be useful to add a comment here why we don't just call 
> CancelBlockedRequestsForRenderView directly.

Done.

http://codereview.chromium.org/16546/diff/207/211#newcode1299
Line 1299: delete requests;
On 2009/01/07 00:16:29, Paul Godavari wrote:
> Will this clean up will have to be done in the destructor too, or can we rely
on
> the channel tear down to do it for us?

When a process is stopped we should be notified and as a result blocked requests
should be deleted.
However it is probably cleaner to make sure we clean left over blocked requests
in the destructor, which is what I did. I also added a unit test which sole
purpose is to turn the Purify bot red if we leak.

[Paul Godavari, 2009-01-08 20:34:32]

LGTM, with one clean up comment:

http://codereview.chromium.org/16546/diff/218/27
File chrome/browser/renderer_host/resource_dispatcher_host.cc (right):

http://codereview.chromium.org/16546/diff/218/27#newcode143
Line 143: // blocked_requests_map_, as it modifies it.
Nit: this block of code is almost identical to the one in
CancelRequestsForRenderView. It would be great if this was a helper function
that could be used in both places.