Kyle, is there any way that your work on https://chromium-review.googlesource.com/c/chromium/src/+/1145580 is related to the dialog not dismissing?

No, that CL hasn't even been submitted yet.

What is the dialog you refer to in your original bug report? Can you include a screenshot?

I mean to say, if your CL was submitted, would it possibly fix this?

Attached screenshot. This is in Smart Lock settings.

Deleted: Screenshot 2018-07-26 at 3.34.28 PM.png 1.1 MB

	Screenshot 2018-07-26 at 3.34.28 PM.png 1.1 MB View Download

No, that's a different type of dialog.

My CL that you linked to in comment #1 is a WebUI dialog, meaning that it is a window which opens on top of the rest of the UI which displays a WebUI page.

The dialog you're referring to is not its own window; rather, it is a <cr-dialog> Polymer element embedded in an existing page. Specifically, it appears to be [1]. I'd suggest debugging that element and its associated JS file.

[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/people_page/easy_unlock_turn_off_dialog.html

This is the offending commit:

https://chromium-review.googlesource.com/c/chromium/src/+/1145588

I suspect that the regression is due to the ToggleEasyUnlockRequest change.

Before my change:
  optional SoftwareFeature feature = 5 [default = EASY_UNLOCK_HOST];

After my change:
  optional string feature = 5 [default = "easyUnlockHost"];

However, I'm not sure why this would cause a problem, since it seems to be the right thing to do here. Jeremy, any ideas why this would cause a problem?

It looks like this code traces down to here:

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/easy_unlock/easy_unlock_service_regular.cc?rcl=a5b73adaf4a5d5ba05236cf3d2096137de1d938b&l=450

If the multidevice API flag is on, or here otherwise:

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/easy_unlock/easy_unlock_service_regular.cc?rcl=a5b73adaf4a5d5ba05236cf3d2096137de1d938b&l=465

Kyle, I think you're right that the root cause here is the feature string change in ToggleEasyUnlock request because the default is now actually a working value. Before, it was just treating the default (and everything else) as null because this feature field wasn't properly serialized. That default null is the approvedForUnlock bit.

The good news is that I believe cl/206347439 will fix this when it makes it to prod CryptAuth. If you want a fix in Dev channel in the meantime, I suggest you try explicitly setting the feature string to null right here and seeing if it works:

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/easy_unlock/easy_unlock_service_regular.cc?rcl=a5b73adaf4a5d5ba05236cf3d2096137de1d938b&l=464

This issue still exists on ToT. Has cl/206347439 fully soaked? Is a client fix necessary here?

Damn :-/ It sounds like it could be related to b/112209799, but may be manifesting slightly differently after that CL rolled out. I'm fully heads-down on that bug right now, so I'll be sure to update this bug with any findings there as well. Either way, I'm confident that this is a server-side issue. 

The server-side issue here is confirmed resolved. I was chatting with Ryan about this earlier this week, but it seems like there may be some incorrect logic here in how feature state is serialized to the db and also in how/when this dialog is closed. Ryan seemed to have a sense of what was wrong here.

Please don't use the ProximityAuth component, it's deprecated.

Ryan, I'm marking this a dupe of 881435. Please repopen if there's still an outstanding issue here.