The chip persists in this case
  https://parkerly.com/sbt (Click "bad subresource")

but does NOT persist in this case
  https://testsafebrowsing.appspot.com (click bad sub resource)

This is on M57/Mac.

Is this different than  https://crbug.com/651055  ?

To my knowledge, it's the same, but that one was mistakenly marked WAI. They are basically dupes tho yes.

This was intended to be fixed in  issue 659709  but apparently wasn't fully.

elawrence, do you think you could take a look at this? There was clearly something wrong with https://codereview.chromium.org/2451623005 which was supposed to fix this... but at least there's a repro (https://parkerly.com/sbt)

Turns out this is a simple fix; it regressed during the SB interstitial componentization, and my test was incomplete so it didn't catch it.

CL at https://codereview.chromium.org/2831583006

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970

commit 2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970
Author: estark <estark@chromium.org>
Date: Fri Apr 21 18:24:57 2017

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}

[modify] https://crrev.com/2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970/chrome/browser/safe_browsing/safe_browsing_blocking_page.cc
[modify] https://crrev.com/2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970/chrome/browser/safe_browsing/safe_browsing_blocking_page_test.cc
[add] https://crrev.com/2a99e9e1b32d0218d1e13a88bb6a7db80dc4a970/chrome/test/data/safe_browsing/malware3.html

TEST=Visit https://parkerly.com/sbt, click "bad-subresources", click "Back to Safety" and verify that the omnibox doesn't say "Dangerous" in the security icon.

(will request a merge to M59 after verifying on canary)

Verified on Canary

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6324e2de1e6645e85166e7f3b7b9bfe9e09a552a

commit 6324e2de1e6645e85166e7f3b7b9bfe9e09a552a
Author: Emily Stark <estark@google.com>
Date: Mon Apr 24 17:55:35 2017

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}

[modify] https://crrev.com/6324e2de1e6645e85166e7f3b7b9bfe9e09a552a/chrome/browser/safe_browsing/safe_browsing_blocking_page.cc
[modify] https://crrev.com/6324e2de1e6645e85166e7f3b7b9bfe9e09a552a/chrome/browser/safe_browsing/safe_browsing_blocking_page_test.cc
[add] https://crrev.com/6324e2de1e6645e85166e7f3b7b9bfe9e09a552a/chrome/test/data/safe_browsing/malware3.html