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}
Committed: https://chromium.googlesource.com/chromium/src/+/2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970

[estark, 2017-04-21 01:46:14]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-21 01:46:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[estark, 2017-04-21 01:53:55]

estark@chromium.org changed reviewers:
+ nparker@chromium.org

[estark, 2017-04-21 01:53:56]

nparker, PTAL?

jialiul: While I was here I noticed that BaseBlockingPage::main_frame_url()
looks like it's unused. Are you planning to use that? If not I can delete it.

[Jialiu Lin, 2017-04-21 02:33:14]

jialiul@chromium.org changed reviewers:
+ jialiul@chromium.org

[Jialiu Lin, 2017-04-21 02:33:14]

LGTM. 

That's some awesome debugging! I didn't realize the temp whitelist handling has
been incorrect util you point it out. 

BTW, let's keep BaseBlockingPage::main_frame_url() for now, it think it will be
useful for WebView (WebView uses BaseBlockingPage to show interstitial instead
of SafeBrowsingBlockingPage).

[commit-bot: I haz the power, 2017-04-21 03:21:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-21 03:21:22]

Dry run: This issue passed the CQ dry run.

[Nathan Parker, 2017-04-21 18:17:27]

lgtm

Great!

[estark, 2017-04-21 18:20:07]

The CQ bit was checked by estark@chromium.org

[commit-bot: I haz the power, 2017-04-21 18:20:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-21 18:25:03]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1492798807219310, "parent_rev":
"24d15b15c85b8d3a60c6985add50824fa6602467", "commit_rev":
"2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970"}

[commit-bot: I haz the power, 2017-04-21 18:25:12]

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
==========

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}
Committed:
https://chromium.googlesource.com/chromium/src/+/2a99e9e1b32d0218d1e13a88bb6a...
==========

[commit-bot: I haz the power, 2017-04-21 18:25:13]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/2a99e9e1b32d0218d1e13a88bb6a...