Fix incorrect |main_frame_url_| parameter to BaseBlockingPage

Fix incorrect |main_frame_url_| parameter to BaseBlockingPage

SafeBrowsingBlockingPage was constructing a BaseBlockingPage using the URL of
the UnsafeResource as the main frame URL. The main frame URL is what gets
removed from the whitelist when the blocking page is dismissed; as a result,
interstitials triggered by cross-origin subresources weren't properly clearing
the whitelist on Back to Safety. This resulted in the Dangerous indicator
sticking around after going back.

We had a test in place for this, but it was incomplete in two ways:
- The malicious subresource was same-origin as the main frame, meaning that the
  whitelist was getting properly cleared "by accident" because it so happens
  that the whitelist URL for the subresource was the same as the main frame URL.
- The test was not checking that if we go back to the hostname on which there
  was an interstitial, the Dangerous indicator does not persist.

BUG=710955
Review-Url: https://codereview.chromium.org/2831583006
Cr-Commit-Position: refs/heads/master@{#466396}
(cherry picked from commit 2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970)

Review-Url: https://codereview.chromium.org/2839703002 .
Cr-Commit-Position: refs/branch-heads/3071@{#170}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
Committed: https://chromium.googlesource.com/chromium/src/+/6324e2de1e6645e85166e7f3b7b9bfe9e09a552a

[estark, 2017-04-24 17:55:52]

Description was changed from

==========
Fix incorrect |main_frame_url_| parameter to BaseBlockingPage

SafeBrowsingBlockingPage was constructing a BaseBlockingPage using the URL of
the UnsafeResource as the main frame URL. The main frame URL is what gets
removed from the whitelist when the blocking page is dismissed; as a result,
interstitials triggered by cross-origin subresources weren't properly clearing
the whitelist on Back to Safety. This resulted in the Dangerous indicator
sticking around after going back.

We had a test in place for this, but it was incomplete in two ways:
- The malicious subresource was same-origin as the main frame, meaning that the
  whitelist was getting properly cleared "by accident" because it so happens
  that the whitelist URL for the subresource was the same as the main frame URL.
- The test was not checking that if we go back to the hostname on which there
  was an interstitial, the Dangerous indicator does not persist.

BUG=710955

Review-Url: https://codereview.chromium.org/2831583006
Cr-Commit-Position: refs/heads/master@{#466396}
(cherry picked from commit 2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970)
==========

to

==========
Fix incorrect |main_frame_url_| parameter to BaseBlockingPage

SafeBrowsingBlockingPage was constructing a BaseBlockingPage using the URL of
the UnsafeResource as the main frame URL. The main frame URL is what gets
removed from the whitelist when the blocking page is dismissed; as a result,
interstitials triggered by cross-origin subresources weren't properly clearing
the whitelist on Back to Safety. This resulted in the Dangerous indicator
sticking around after going back.

We had a test in place for this, but it was incomplete in two ways:
- The malicious subresource was same-origin as the main frame, meaning that the
  whitelist was getting properly cleared "by accident" because it so happens
  that the whitelist URL for the subresource was the same as the main frame URL.
- The test was not checking that if we go back to the hostname on which there
  was an interstitial, the Dangerous indicator does not persist.

BUG=710955

Review-Url: https://codereview.chromium.org/2831583006
Cr-Commit-Position: refs/heads/master@{#466396}
(cherry picked from commit 2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970)

Review-Url: https://codereview.chromium.org/2839703002 .
Cr-Commit-Position: refs/branch-heads/3071@{#170}
Cr-Branched-From:
a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
Committed:
https://chromium.googlesource.com/chromium/src/+/6324e2de1e6645e85166e7f3b7b9...
==========

[estark, 2017-04-24 17:55:54]

Committed patchset #1 (id:1) manually as
6324e2de1e6645e85166e7f3b7b9bfe9e09a552a.