Chrome Version       : 61.0.3135.4
All platforms.

What steps will reproduce the problem?
0. On Mac: System Prefs -> Keyboard -> Shortcuts -> Ensure "All Controls is set under "Full Keyboard Access"
1. https://permission.site/ -> padlock -> ensure everything is set to Ask. Reload.
2. Click Notifications
3. Press Tab (a few times)

What is the expected result?

On all platforms, the same thing. Which is either:

 (a) Focus switches between the two dialog buttons, or
 (b) Focus switches between the two dialog buttons and the close [x]


What happens instead of that?

 - Mac does (b). Both with and without --secondary-ui-md
 - Everything else does (a).


Note this is separate to VoiceOver navigation, which should always navigate over the close [x], as well as labels in the dialog.

Plan: Do (a) on Mac as well -> https://codereview.chromium.org/2982533002


Note (b) happens on Mac with --secondary-ui-md because views::Button defaults to:

Button::Button(ButtonListener* listener)
    : listener_(listener),
      tag_(-1) {
  SetFocusBehavior(FocusBehavior::ACCESSIBLE_ONLY);
}


On non-Mac, this means the button only gets a Tab Stop when the button is in an AccessiblePaneView AND focus traversal is done via F6 rather than Tab.
On Mac this is what is controlled by System Prefs' "Full Keyboard Access" (Mac will never want or need AccessiblePaneView)


Basically.. this bug boils down to BubbleFrameView never making a conscious choice for what the focus behaviour for its button should be.

Since the dialog button close[x] is (effectively) additionally activated by ESC in DialogClientView, or is often a redundant button from some actual dialog button, then removing the close[x] from focus order on all platforms consistently seems the right choice to me. That's what https://codereview.chromium.org/2982533002 does. Note this does not affect the ability for a11y screen readers to focus and activate the close button (tested Windows Narrator and VoiceOver)