Joe, could you take a look?

Sure

On tot, the dialog cannot be closed is because of:  issue 707817 

Without the above offending CL (like M-58), I could not get a repro.
aashutoshk@, for "The authentication dialog persists and the icon continues showing the exclamation mark", do you mean always there, never disappear?

In my experiment, I could see they just persist for some seconds. I would like to know more information about it. Thanks!

As discussed with warx@ in private conversation, just updating the issue with the same comment.

The authentication dialog is always there and does not disappear on it own, it requires user to dismiss the dialog. Also, it is not always reproducible. 

I can repro when the dialog is shown (behind captive portal) and the chromebook is moved far away from the router. From the attached logs, I also saw many portal detection timeout logs.
I think my CL should be blamed: https://codereview.chromium.org/2756643002/. Without my CL, dialog takes some time but will finally automatically closed, but with my CL, it takes "forever" time to be closed.

The change I do is: when we are successfully behind captive portal, no next attempt is scheduled to reduce attempt tries. However, the current logic for closing dialog is still relied on captive portal detection: [1]

Since we don't schedule active portal detection when behind captive portal, the only chances that will do portal detection are DefaultNetworkChanged or proxy changed. If there is an online network connection state changed, we probably need to close the dialog directly instead of relying on portal detection online status as this could be getting lost.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/net/network_portal_notification_controller.cc?l=286

 Issue 711202  has been merged into this issue.

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

commit 4179f08f0a422e3f78c822565cc067fee99987e9
Author: warx <warx@chromium.org>
Date: Wed Apr 19 22:11:22 2017

cros: close dialog when shill detects captive portal network switched to online

Changes:
(1) On crrev.com/2756643002, we stop the chrome portal detector attempts when chromebook is successfully behind the captive portal. Thus, the following passive attempts are only triggered by network state change or proxy change, like auth supplied. Currently, the portal dialog auto-close happens if chrome portal detection detects an online result. This used to be robust since we keep doing active chrome detection when we are behind the portal. But now if shill detects a online state, it triggers chrome portal detection but this detection times out (indicating that wifi is bad so that fetching gives no response). To make it robust, we can close the dialog when shill detects captive portal network switched to online state.

(2) SetIgnoreNoNetworkForTesting() is not needed any more since in tests, SetConnected happens before dialog is shown. The dialog wont be auto-closed for the tests.

BUG= 705813 
TEST=test that portal dialog can be closed when wifi signal is not that good.

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

[modify] https://crrev.com/4179f08f0a422e3f78c822565cc067fee99987e9/chrome/browser/chromeos/net/network_portal_detector_impl_browsertest.cc
[modify] https://crrev.com/4179f08f0a422e3f78c822565cc067fee99987e9/chrome/browser/chromeos/net/network_portal_notification_controller.cc
[modify] https://crrev.com/4179f08f0a422e3f78c822565cc067fee99987e9/chrome/browser/chromeos/net/network_portal_notification_controller.h

Please have a test on Canary when it is ready. Will do the merge if canary looks good.

For a record, CL is picked into branch 60.0.3076.0

Assigning to aashutoshk@ for verification.

 Issue 714600  has been merged into this issue.

What is the status here? Note: once verified, the fix CL needs to be merged to M59.

This is still reproducible. Tested on Kevin and Samus R60-9554.0.0

This problem always appears after the session expires and user tries to authenticate again.  

Discussed with aashutoshk@, the repro steps are:
(1) connected to a captive portal
(2) portal side disconnects the connected device
(3) a portal notification message bubble will show again
(4) authenticate now in the dialog, can see dialog not dismissed

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

commit 6ce76f805592a7be9a1a7ee470cba75eba4d9585
Author: warx <warx@chromium.org>
Date: Thu May 25 21:41:20 2017

Revert "cros: Do not schedule attempt when behind captive portal with response 200 is detected"

This reverts commit db14329b13d1109723acf5528a0253d6ee8c1651, reviewed on: https://codereview.chromium.org/2756643002

This should get rid of the existing issue of 705813. Do not schedule
attempts when behind portal is causing the trouble. When portal side
disconnects the connected device, and device reconnects, shill doesn't
report network changed. This case should be handled. Let us reconsider
the reducing detection attempts approach.

BUG=702273,  705813 ,  718094 
TEST=705813 is fixed. We shall reconsider the reducing detection
attempts approach.

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

[modify] https://crrev.com/6ce76f805592a7be9a1a7ee470cba75eba4d9585/chrome/browser/chromeos/net/network_portal_detector_impl.cc
[modify] https://crrev.com/6ce76f805592a7be9a1a7ee470cba75eba4d9585/chrome/browser/chromeos/net/network_portal_detector_impl_unittest.cc

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

commit 82d96071a0cafd9bbf00629a1a537550a826e222
Author: Qiang Xu <warx@chromium.org>
Date: Thu May 25 21:47:47 2017

[Merge to M59] Revert "cros: Do not schedule attempt when behind captive portal with response 200 is detected"

This reverts commit db14329b13d1109723acf5528a0253d6ee8c1651, reviewed on: https://codereview.chromium.org/2756643002

This should get rid of the existing issue of 705813. Do not schedule
attempts when behind portal is causing the trouble. When portal side
disconnects the connected device, and device reconnects, shill doesn't
report network changed. This case should be handled. Let us reconsider
the reducing detection attempts approach.

TBR=stevenjb@chromium.org
BUG=702273,  705813 
TEST=705813 is fixed. We shall reconsider the reducing detection
attempts approach.

Review-Url: https://codereview.chromium.org/2910503002
Cr-Original-Commit-Position: refs/heads/master@{#474815}
Review-Url: https://codereview.chromium.org/2910543002 .
Cr-Commit-Position: refs/branch-heads/3071@{#695}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/82d96071a0cafd9bbf00629a1a537550a826e222/chrome/browser/chromeos/net/network_portal_detector_impl.cc
[modify] https://crrev.com/82d96071a0cafd9bbf00629a1a537550a826e222/chrome/browser/chromeos/net/network_portal_detector_impl_unittest.cc

fixed by reverting crrev.com/2756643002

aashutoshk@ - please test and verify.

Works as expected. Kevin 9460.60.0