There is a reason why it can't be done in some of the cases. It's automatic handling of ESC.
- AccountChooserDialogView already uses GetDialogButtons().
- AutoSigninFirstRunDialogView: ESC shouldn't press "Turn off". Thus, "Turn off" can't be a Cancel button in the code.
- ManagePasswordsBubbleView: ESC shouldn't press the "Never" button. Actually, this bubble is a frame for many concrete view. Some of them can use GetDialogButtons() while other can't.

We need to address that in a different way than rolling custom buttons.  My argument is that esc needs to behave consistently in all these dialogs, which means we decide which button is "cancel" and which is "accept", and esc always presses cancel, even if it doesn't today.  The behavior today violates a11y and consistency principles.  But if for some reason we decide otherwise, the right solution is a hook to allow a dialog to say what esc does, not rolling its own buttons.

vasilii@chromium.org,  since you -1d the code review on this, you are now on the hook to address comment 2 (or find someone who can) within the next couple of days.

I suggest working with hwi@ to resolve some of this.

pkasting@, you are not my manager to assign tasks to me and set deadlines. If it's unclear to you for some obscure reason, go to the ladder and talk to the relevant people.

Our team doesn't have a dedicated UXer at the moment.

I'm going to chat further with pkasting@ on this in person, and get back to this bug again. Give me a week or two.

As stated in c#1, the following example dialogs take Esc to dismiss the dialogs WITHOUT making any selection on the buttons. It's an intended behavior to support "undecided" state while keeping Esc as a consistent way to close a dialog. 
- Auto signin first run
- Password save
- Permissions (i.e. Esc doesn't explicitly block the requested permission but only temporarily for the session)  crbug.com/609079#c16 

re: c#2 - "a hook to allow a dialog to say what esc does, not rolling its own buttons" 
pkasting@, do you mind letting me know whether or not the hook could potentially continue to support the cases above? Thanks!

Like I said in https://chromium-review.googlesource.com/c/557139, such a hook for specifying the "no decision" case already exists. See DialogDelegate::Close (https://chromium.googlesource.com/chromium/src/+/51748c71e51e538a7dd2f1ec60a7c98cc02acdd0/ui/views/window/dialog_delegate.h#84).

I apologize for communicating poorly -- most obviously in comment 3, which was too brusque, but also before that, when I failed to make it clear I was waiting on followup and who I expected to provide it.  I'm sorry, Vasilii.

As noted in comment 5, I'll chat with Hwi about the larger pattern.  I've also been in communication with battre@ about this stuff.  We'll make sure all stakeholders are happy.  To that end, assigning this to myself to own the behavioral decision part.

Per comment 6, it seems like the CR in question here doesn't actually change behavior, so maybe it can move forward in the short term?

There was a misunderstanding on the CL which I already approved. Thus, AutoSigninFirstRunDialogView is properly fixed.

Regarding ManagePasswordsBubbleView. We have actually added an Edit button recently so that the layout of the "Save password?" bubble will be:

username      ******
 
[Edit]        [Save] [Never]

I don't think that this pattern for buttons is supported by the framework.

It's supported; we can do up to three buttons.

\o/

Great to see that we could resolve the issues.

With https://chromium-review.googlesource.com/c/557139/ landed, can we close this?

Let's leave it open for now, I still need to converse with Hwi tomorrow about this stuff.

Here's a follow-up. pkasting@, thanks for the discussion. Please feel free to chime in. 

The Esc behavior on the password dialogs, both before and after the cl on c#10, are inline with the current/Harmony rules.

This is the current set of rules, and Harmony intends to continue to support it:

a. Pressing Esc always dismisses the active/focused dialog regardless of presence of Cancel or Close_X button. 
b. Pressing Esc never takes any additional actions other than dismissing a dialog.

Rationale/assumption: Esc being used to dismiss a dialog is commonly understood and expected. It’s less commonly expected for Esc being used to map to a certain button or to undo action. Mapping multiple actions to a single keypress could end up causing different mental model build-up.

For ongoing reference/refinement: go/harmony-esc

I think all the work here has been done.