+Password manager folks.

I don't think I'd consider the current behavior a security bug, but it does seem like we could flip the default focus to something less likely to surprise users.

Sabine, et al: is the current behavior a conscious decision from a product perspective?

I don't consider it a bug because I didn't feel that the second press is handled before the dialog is shown.
It was a conscious decision aligned with the Windows spec (https://msdn.microsoft.com/en-us/library/windows/desktop/dn742465.aspx, "The OK button is normally the default button").

Hwi, any thoughts on this?

I also think that it probably makes sense to keep the button as the default button, since I believe this is how most dialogs work in Chrome.

It isn't the case that there is a default button in all cases where you have a dialog. In the case where opting the affirmative action unintentionally could have unwanted effects, the default action could be left out. An example is the permission prompts,  issue 619429 . 

re: #C2 -  vasilii@, it seems that, if the keyboard event propagation is stopped at the first dialog and not carried on to the second dialog, the user can have a better chance to avoid accidentally submitting the second dialog without reading it. Currently, I see  a swift double-entering from the first dialog open & submit the second dialog too quickly. 

(Enough knowledgeable people on this thread already.)

What is the first dialog? There is just the account chooser.
Did you feel that the second press still happened on the web page?

#c8 - vasilii@, 

My bad, I misread the original description (confused with the first run flow). Apologies for any confusion and creating a distraction. 

Back to the issue, 

- In a few instances during a user study, an observation was that not having a sign-in button on a single account case led them to feel unclear of what the right action was to proceed. The Sign in button was added to address the issue. Also it's made to be default to further optimize sign-in flow since it's more likely that the account chooser is called from sign-in context (vs. non sign-in context). 

- Quick double presses of Enter key from a web page can lead to an accidental sign-in from the account chooser without having a chance to read the chooser dialog. IMHO, if there's a general way to accept multi-keypresses as a single press when keypressing happens in a very short time (assuming it's an accidental keypressing), that might mitigate the problem to this crbug as well as other similar problems, e.g. Printing accidentally without confirming when double pressing Print button from a page. 

sky@, is there any way to detect/suppress double key press events?