I marked this as Release blocker M68. Bernie, could you please estimate importance of this.

Link to video:
https://drive.google.com/file/d/1VCuHLiANTiz53kUfD284AkWvPqR5JBPh/view?usp=sharing

I am not able to reproduce this issue on Eve running R68-10718.88.1, will upgrade the device to R68-10718.93.0 and report back. 
video link here@ https://drive.google.com/file/d/16wsLV5Y-aJJAF_oEG3ak2BykNSgmsLWe/view?usp=sharing

For M68, I can reproduce this issue on Nami running R68-10718.93.0 but not on Eve running the same build. 
Eve video here: https://drive.google.com/file/d/19IQE8CbvQ2m9oE9oDBNx3M6xND_j8Mcq/view

Tested the following, 

1) Sona (Nami Family) R68-10718.93.0 -- Good. 
https://drive.google.com/file/d/1zxiSw5ZQVaihBPXgNmZAREWvqVCNnkBs/view?usp=sharing
2) Kevin R69-10895.33.0 -- Good
3) Eve  R70-10994.0.0 -- Bad - Sees this issue. 

AFAIK Nami device is an old reference board, and we should be using other devices in the family like Sona, Pantheon, Alkali, Alkali360 (use Nami image but different family) for testing. 

Is this good enough checking to remove M-68 and ReleaseBlock-stable label? I will add M-70 label.

+WiFi folks for thoughts

If this actually happens with any reliability on 68 it is a real problem, however 68 is already substantially rolled out to stable, so we may be too late. 

We should see if this happens anywhere on the earlier version of 68 that went out, and evaluate if we should stop the roll out. 

Seeing this issue on Nocturne( 10991.0.0, 70.0.3524.2)

happens in 67 :( (tested on cyan)

If this happens back to 67, I am afraid we cannot really block on it, this just becomes a high priority issue.

Kirtika, is this in your jurisdiction?

Reproing at my end, but this sounds like a UI issue.

Assigning so this doesn't get lost in the sea of untriaged bugs...

Steps 5/6 are unclear, could you be more specific?

I can not reproduce this on 70.

#12 could you refer to video in #3 0:36? Just repro recent eve (m71). It sometimes works on first attempt but in this case always reproducible on second attempt.

OK, watching the video from comment #3 I was able to repro this.

The first half of the video is  issue 870903 , which has been fixed.

The second half can be reproduced more simply (step 4 is the key and why some of us were unable to repro this):

1. Open Settings with no network connection.
2. Click on WiFi.
3. Select a secure unconfigured wifi network to connect to. The dialog should appear.
4. Close the dialog with 'ESC'.
5. Select the network again (or any secure, unconfigured network).

Observe: The connect dialog does not occur. Clicking the 'details' arrow then 'Connect' or 'Configure' has the same issue. Reloading the Settings page will fix the issue.

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

commit c39ff10cfa693c49f4167dc6c34081df76d72f80
Author: dpapad <dpapad@chromium.org>
Date: Sat Sep 08 03:07:48 2018

WebUI: Update cr-dialog 'open' property on Escape.

Currently if Escape is used to close a cr-dialog, the 'open' property
is not getting set to false, which causes dialogs to not be re-opened in some
cases.

Slight modification of original fix by stevenjb@.

Bug:  877122 
Change-Id: Ib39a0e20bbf2318045844b39794335e49829faf4
Reviewed-on: https://chromium-review.googlesource.com/1213954
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589764}
[modify] https://crrev.com/c39ff10cfa693c49f4167dc6c34081df76d72f80/chrome/test/data/webui/cr_elements/cr_dialog_test.js
[modify] https://crrev.com/c39ff10cfa693c49f4167dc6c34081df76d72f80/ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js

@Steven: Is this now fixed?

Confirmed fixed on ToT. Requesting merge. (dpapad@, I can do the merge once approved).

+Geo for quick approval. 
This will be needed for Meowth as well. 

> dpapad@, I can do the merge once approved

Thanks Steven, that would be helpful.

Approved for M70.

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

commit fe764053742a3bc149be38581995d0876a08a401
Author: Steven Bennetts <stevenjb@chromium.org>
Date: Mon Sep 10 19:32:53 2018

WebUI: Update cr-dialog 'open' property on Escape.

Currently if Escape is used to close a cr-dialog, the 'open' property
is not getting set to false, which causes dialogs to not be re-opened in some
cases.

Slight modification of original fix by stevenjb@.

TBR=dpapad@chromium.org

(cherry picked from commit c39ff10cfa693c49f4167dc6c34081df76d72f80)

Bug:  877122 
Change-Id: Ib39a0e20bbf2318045844b39794335e49829faf4
Reviewed-on: https://chromium-review.googlesource.com/1213954
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#589764}
Reviewed-on: https://chromium-review.googlesource.com/1217345
Cr-Commit-Position: refs/branch-heads/3538@{#240}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/fe764053742a3bc149be38581995d0876a08a401/chrome/test/data/webui/cr_elements/cr_dialog_test.js
[modify] https://crrev.com/fe764053742a3bc149be38581995d0876a08a401/ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js