Workaround a SafeBrowsingBlockingPage crasher

A crash report from the field reports that we are removing a SafeBrowsingBlockingPage from a global map that is not to be found causing a stl exception to be thrown.
I am not sure what the cause is yet, my investigations results are in the bug comment.
This is a work-around the crasher while I keep investigating.

BUG=9442
TEST=Access a page which contains sub-resource malware.

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

[Paul Godavari, 2009-03-28 01:34:53]

http://codereview.chromium.org/49049/diff/1/2
File chrome/browser/tab_contents/interstitial_page.cc (right):

http://codereview.chromium.org/49049/diff/1/2#newcode133
Line 133: tab_to_interstitial_page_->erase(iter);
LGTM.

Could this be due to multiple malware resources on the same page causing a
second interstitial to be shown or added to the list of resources on the first
interstitial page?

[jcampan, 2009-03-28 01:42:22]

http://codereview.chromium.org/49049/diff/1/2
File chrome/browser/tab_contents/interstitial_page.cc (right):

http://codereview.chromium.org/49049/diff/1/2#newcode133
Line 133: tab_to_interstitial_page_->erase(iter);
On 2009/03/28 01:34:54, Paul Godavari wrote:
> LGTM.
> 
> Could this be due to multiple malware resources on the same page causing a
> second interstitial to be shown or added to the list of resources on the first
> interstitial page?

Shouldn't be the case anymore. I added some code few months ago to deal with
these exact cases. It queues interstitials if more than one is displayed.