These two lines show up right when the password prompt dialog comes up, before the user has a chance to type anything, so looks like some callback is badly wired, passing down the password too early when that field is empty: 

[1735:1735:0207/194000.886693:ERROR:device_event_log_impl.cc(137)] [19:40:00.886] Network: network_connection_handler.cc:789 Connect Failure: passphrase-required: /service/1
[1735:1735:0207/194000.887162:ERROR:device_event_log_impl.cc(137)] [19:40:00.886] Network: network_connect.cc:197 Connect Failed: passphrase-required: 841123e7-d115-40d8-9039-d7340c2f5816

Also, I noticed that hitting "Ctrl+Enter" after typing the password works, but hitting Enter alone does not. Maybe ui::VKEY_RETURN being used somewhere where we need ui::VKEY_ENTER ? 

<insert I-have-no-idea-what-I-am-doing-dog-meme here>

Able to reproduce on 58.0.3001.0 but not 58.0.2993.0.

Does not show up on 58.0.2998.0 either.
CC-ing a few folks who touched network/wifi related files between 58.0.2998.0 and 58.0.3001.0. 

The callback in #c1 may be a red herring since I see those logs in the good case as well. Or it may be the issue that got exposed by some other change. 

To clarufiy:

(2) Select a WPA2 network from any UI surface (OOBE, status area, or settings). This will bring up the wifi connect dialog.
(3) Type in a password and hit enter (do not click "Connect")

This dismisses the dialog without attempting a connection.

Re comment #1, those messages are expected (although we should probably make them INFO not ERROR when no password has been set), that is how we trigger the dialog in the first place since the UI does not know whether or not the network is configured.

This is almost certainly either:

https://codereview.chromium.org/2668853002: Use the CreatePanelLayout() utility method instead of hand-rolling panel layout

or

https://codereview.chromium.org/2659973003: Harmony Chrome OS Wifi dialog.

xdai@ - Can you determine which of these is the cause?

I am re-prioritizing this as a P1 Stable Blocker since there is a workaround (click the 'connect' button).

I think it's caused by my CL https://codereview.chromium.org/2659973003: Harmony Chrome OS Wifi dialog. Before this change, the default button is "Connect" button but this CL changed it to "Cancel" button according to the new spec: https://improv.googleplex.com/projects/ahtzfmdvb2dsZS5jb206aW1wcm92LXNlcnZpY2VyEAsSB1Byb2plY3QY4Za9OQw/files/ahtzfmdvb2dsZS5jb206aW1wcm92LXNlcnZpY2VyJgsSCkNvbGxlY3Rpb24YgICA4L-7hQoMCxIIUmVzb3VyY2UYkU4M. And that's the reason the dialog was dismissed when enter was hit. I can change it back. 

Yes please, 'Connect' should be the default. ('Enter' should not do anything until a valid, i.e. long enough, password has been entered).

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

commit 71afff610bb36f19c52564fc5801143fbeaab8f3
Author: xdai <xdai@chromium.org>
Date: Fri Feb 10 01:23:51 2017

Change the default button of Network Wifi config dialog back to 'Connect'.

The default button was changed from 'Connect' to 'Cancel' in
https://codereview.chromium.org/2659973003, which caused the regression.

BUG= 689795 

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

[modify] https://crrev.com/71afff610bb36f19c52564fc5801143fbeaab8f3/chrome/browser/chromeos/options/network_config_view.cc
[modify] https://crrev.com/71afff610bb36f19c52564fc5801143fbeaab8f3/chrome/browser/chromeos/options/network_config_view.h

I can't see the spec link right now (please link to Folio instead), but in general, please be very careful about functional changes when Harmonizing as we should always understand whether the functional change was intended, what the design goal of the change was, and how to deal with it going forward.

If we need to revert such a change, please feed that back to the UX design team so they can update the spec or counterargue, as these specs will be the basis of future changes as well.

 Issue 691309  has been merged into this issue.