Destroying the webview is tricky. Can we make the webview navigate away from the idp page, say about:blank? We can do that in Authenticator.resetStates_, which would be called when the online flow is canceled.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/gaia_auth_host/authenticator.js&l=199

Thanks for the idea, Xiyuan.
However, I've already created a CL (crrev.com/1988113004) where a different approach is attempted: calling Authenticator.reload which reloads webview to the starting URL. Do you think there may be issues with this solution?

OK, so, according to review comments, redirecting to "about:blank" is a more correct solution.

However, I've discovered issues of another sort.

When a network is suddenly disconnected while displaying the SAML webview, the webview just becomes hidden (initially the SAML_INTERSTITIAL screen is displayed, and in several seconds it's replaced by the network error screen). The webview is kept running in the background, even after these screens are shown. Neither GaiaSigninScreen.reset nor Authenticator.resetStates_ are called.

I believe the code responsible for this behavior lives in the setter method GaiaSigninScreen.set screenMode. The method implementation manipulates only the "hidden" DOM attributes, without doing actual resetting of the hidden frames.

The question is: is this behavior intentional? Are there scenarios where it's important to keep the webview hidden, and then later show it with the same location?

If not, we could try performing reset from this screenMode setter method (though I don't know whether this is an appropriate place).

IMHO, we should not keep webview state when it is hidden and re-shown.

How about do a authenticator.resetStates_ (make it clear webview src as well) in GaiaSigninScreen.onBeforeHide ?

> How about do a authenticator.resetStates_ (make it clear webview src as well) in GaiaSigninScreen.onBeforeHide ?

Turns out, GaiaSigninScreen.onBeforeHide is not called in the discussed case too.
I'm testing now adding the reset into GaiaSigninScreen.loadAuthExtension, which is called immediately when the SAML page is about to be hidden.

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

commit 9ac3388d7cb865125b9af3c4e562a9677412e206
Author: emaxx <emaxx@chromium.org>
Date: Tue Jun 14 20:07:51 2016

Clear the login webview when SAML flow is canceled

Previously, the SAML webview running third-party website was kept
running in the background even after the SAML login flow is
canceled.

This CL adds a redirection of the SAML webview to a blank page
each time the login screen mode is changed.

BUG= 613245 
TEST=existing login tests, manual testing with going to camera-capturing
SAML web page and checking that the camera lid is off once the SAML flow
is canceled manually or terminated due to a timeout or canceled due to
network disconnection

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1988113004
Cr-Commit-Position: refs/heads/master@{#399769}

[modify] https://crrev.com/9ac3388d7cb865125b9af3c4e562a9677412e206/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/9ac3388d7cb865125b9af3c4e562a9677412e206/chrome/browser/resources/gaia_auth_host/authenticator.js

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

commit 9ac3388d7cb865125b9af3c4e562a9677412e206
Author: emaxx <emaxx@chromium.org>
Date: Tue Jun 14 20:07:51 2016

Clear the login webview when SAML flow is canceled

Previously, the SAML webview running third-party website was kept
running in the background even after the SAML login flow is
canceled.

This CL adds a redirection of the SAML webview to a blank page
each time the login screen mode is changed.

BUG= 613245 
TEST=existing login tests, manual testing with going to camera-capturing
SAML web page and checking that the camera lid is off once the SAML flow
is canceled manually or terminated due to a timeout or canceled due to
network disconnection

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1988113004
Cr-Commit-Position: refs/heads/master@{#399769}

[modify] https://crrev.com/9ac3388d7cb865125b9af3c4e562a9677412e206/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/9ac3388d7cb865125b9af3c4e562a9677412e206/chrome/browser/resources/gaia_auth_host/authenticator.js

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

commit c6a537d7c1244a6892de34d80cf564c97270f21e
Author: jdufault <jdufault@chromium.org>
Date: Wed Jun 15 16:37:21 2016

Revert of Clear the login webview when SAML flow is canceled (patchset #8 id:140001 of https://codereview.chromium.org/1988113004/ )

Reason for revert:
Makes SAMLPolicyTest.SAMLInterstitialNext extremely flaky. See  crbug.com/620353 .

Original issue's description:
> Clear the login webview when SAML flow is canceled
>
> Previously, the SAML webview running third-party website was kept
> running in the background even after the SAML login flow is
> canceled.
>
> This CL adds a redirection of the SAML webview to a blank page
> each time the login screen mode is changed.
>
> BUG= 613245 
> TEST=existing login tests, manual testing with going to camera-capturing
> SAML web page and checking that the camera lid is off once the SAML flow
> is canceled manually or terminated due to a timeout or canceled due to
> network disconnection
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
>
> Committed: https://crrev.com/9ac3388d7cb865125b9af3c4e562a9677412e206
> Cr-Commit-Position: refs/heads/master@{#399769}

TBR=achuith@chromium.org,afakhry@chromium.org,xiyuan@chromium.org,emaxx@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 613245 

Review-Url: https://codereview.chromium.org/2068953003
Cr-Commit-Position: refs/heads/master@{#399923}

[modify] https://crrev.com/c6a537d7c1244a6892de34d80cf564c97270f21e/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/c6a537d7c1244a6892de34d80cf564c97270f21e/chrome/browser/resources/gaia_auth_host/authenticator.js

Moving this nonessential bug to the next milestone.

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/+/93dc10b6eaaf3be6c4634a2e91e671da21338424

commit 93dc10b6eaaf3be6c4634a2e91e671da21338424
Author: emaxx <emaxx@chromium.org>
Date: Mon Jun 20 17:09:45 2016

Reland of Clear the login webview when SAML flow is canceled (original CL crrev.com/1988113004).

The original CL was later reverted (CL crrev.com/2068953003) due to
frequent failures of the SAMLPolicyTest.SAMLInterstitialNext test.

This follow-up CL should resolve the tests flakiness.

The problem with the original CL was that it could introduce raising the
"ready" event too early, so that the test code could start working when
the webview was still pointing to the blank page.

BUG= 613245 , 620353 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2082533002
Cr-Commit-Position: refs/heads/master@{#400703}

[modify] https://crrev.com/93dc10b6eaaf3be6c4634a2e91e671da21338424/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/93dc10b6eaaf3be6c4634a2e91e671da21338424/chrome/browser/resources/gaia_auth_host/authenticator.js

Marked the issue back a M-52 as the fixed bug was a potential privacy hole.

Scott/Krishna, could you please perform the manual testing once the change reaches the next build?

The testing, in addition to verifying the scenarios tested in  issue 606979  still work, should verify that after the SAML flow is canceled, the SAML page is not working anymore.
Possible testing scenario: start a SAML flow with a page that performs camera capturing, ensure that camera LED is on, then cancel the SAML flow and ensure that the camera LED becomes off. Example ways of canceling the SAML flow:
a) close by clicking at 'x';
b) disconnect from the network;
c) wait until 90 seconds timeout passes.

Test Update: The refactored CL hasn't made it into the latest TOT(53.0.2773.0) yet. 
Will check on Mondays's build

Test Update: The refactored CL hasn't made it into the latest TOT(53.0.2773.0) yet. 
Will check on tomorrow's build.

Krishna, I think my change finally reached builds for M53. Could you please arrange the testing?

Tested that this works on R53: 53.0.2785.4:8530.6.0.
Tested that the SAML IdP page is redirected  to the about:blank page when the IdP page is dismissed. (by  clicking at 'x', disconnecting from the network, waiting until 90s timeout passes)  
Verified with IdP's that require require video capture.
Verified with OKTA.
Verified that when the IdP page is dismissed the camera light is turned off. 
Adding a merge request to R52

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 4aa965d679259cc8545572fd4a34688671920711
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Fri Jul 08 01:14:01 2016

Reland of Clear the login webview when SAML flow is canceled (original CL crrev.com/1988113004).

The original CL was later reverted (CL crrev.com/2068953003) due to
frequent failures of the SAMLPolicyTest.SAMLInterstitialNext test.

This follow-up CL should resolve the tests flakiness.

The problem with the original CL was that it could introduce raising the
"ready" event too early, so that the test code could start working when
the webview was still pointing to the blank page.

BUG= 613245 , 620353 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2082533002
Cr-Commit-Position: refs/heads/master@{#400703}
(cherry picked from commit 93dc10b6eaaf3be6c4634a2e91e671da21338424)

Review URL: https://codereview.chromium.org/2134543003 .

Cr-Commit-Position: refs/branch-heads/2743@{#596}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/4aa965d679259cc8545572fd4a34688671920711/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/4aa965d679259cc8545572fd4a34688671920711/chrome/browser/resources/gaia_auth_host/authenticator.js

@Krishna, I assume you also verified that this can be done multiple times in a row? We had some issues with restarting the flow especially when video was there. Would be great if we can vet that this is indeed gone.

Tested that this works on R53: 	8350.60.0;52.0.2743.85
Tested that the SAML IdP page is redirected  to the about:blank page when the IdP page is dismissed. (by  clicking at 'x', disconnecting from the network, waiting until 90s timeout passes)  
Verified with IdP's that require require video capture.
Verified with OKTA.
Verified that when the IdP page is dismissed the camera light is turned off. 
Verified that video capture on the IdP page and subsequent sign in works even after the Video capture IdP page is dismissed multiple times.