Hmm... I don't think tab should travel from the omnibox to the page, because it should also travel to the wrench menu in the case of no extensions being installed or to the first extension.  That said, it does look like it takes two tabs from the omnibox to reach the next button (either extension or wrench menu), so that is a bug.

@rdevlin: If that is the case, there needs to be a :focus treatment on those buttons, right now you cannot see what has focus, which is very confusing.

I also disagree that extensions should be reachable by tab, as you can't interact with them using the keyboard (maybe that's a separate bug), and reaching the page is what you'll want to do 99% of the time.

Why do you say that you can't interact with the extension buttons after focus has been placed on them with tab or shift-tab? (BTW, are we testing with shift-tab?)
Let's try and follow platform convensions. Tab and shift-tab behavior should change based on keyboard settings in system preferences. The same settings can be altered by using ctrl-f1 and ctrl-f7. You may want to consider what these settings do and read up on them. They are implemented by Apple apps.

@3 - You should be able to interact with the extension buttons by using the activation key (typically space I think, but it can be changed).  And there should also already be focus treatment applied to them, at least on most version of OS X 10.8+.  See revision 9c75e3773754cfb242c2819cbfb45bd8b5ddf95f.  Screenshot attached.

Deleted: Screen Shot 2016-03-09 at 11.37.43 AM.png 10.2 KB

	Screen Shot 2016-03-09 at 11.37.43 AM.png 10.2 KB View Download

Oh interesting, I didn't know about ctrl+F1 ctrl+F7.

If I don't have keyboard access on (the default):

1. Location bar
 <tab>
2. Somewhere broken
  <tab>
3. The page

If I do have keyboard access on (and I've pressed ctrl+F7 to "change the way Tab moves focus"):
1. Location bar
  <tab>
2. Somewhere broken
  <tab>
3. Focusses extension icon (hitting space doesn't do anything, hitting enter doesn't do anything, I'd expect it to open the menu that opens when I click on an extension icon)
  <tab>
4. Focusses menu (hitting space opens the menu)
  <tab>
5. Focusses page.


So I think there are two bugs:

1. <tab> gets lost after the location bar.
2. <space> on extension icons doesn't open the menu.

Okay.  The "Somewhere broken" step should be fixed soon (patch should be landing shortly).  The fact that the action isn't doing anything on keyboard action might be related to the fact that we forward left-clicks on otherwise-disabled extensions to the context menu, and it looks like we need to update it to do the same for keyboard interaction.  Can you confirm if for an extension with a browser action, hitting space (assuming that's the interaction key for you) does something?

Awesome, thanks for the fast turn-around.

Yes, you're right, it works for extensions with browser actions, but not for all the other ones that show up there now.

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

commit dc68af6738e9b8f5c1d2546f67d2bb145e9f74b5
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Wed Mar 09 20:15:41 2016

[Extensions UI Mac] Don't let the top-level actions container be first responder

The overflow browser actions container needs to accept first responder in order
to allow in-menu keyboard navigation; however, the top-level container doesn't
need to do this. Don't allow it to become first responder so that focus travels
correctly between the omnibox and either the first action or the wrench menu.

BUG=592825

Review URL: https://codereview.chromium.org/1782513002

Cr-Commit-Position: refs/heads/master@{#380197}

[modify] https://crrev.com/dc68af6738e9b8f5c1d2546f67d2bb145e9f74b5/chrome/browser/ui/cocoa/extensions/browser_actions_container_view.mm

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

commit 98f7b6d97ccaa3c469319a0e1bbc051885847d0b
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Fri Mar 11 17:21:08 2016

[Extensions UI Cocoa] Make disabled actions respond to the keyboard

There was a bug where an otherwise-disabled action wouldn't respond to key
presses. Fix this, and add a test.

BUG=592825

Review URL: https://codereview.chromium.org/1784533003

Cr-Commit-Position: refs/heads/master@{#380659}

[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/cocoa/extensions/browser_action_button.h
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/cocoa/extensions/browser_action_button.mm
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/cocoa/extensions/browser_action_button_interactive_uitest.mm
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/cocoa/extensions/extension_action_platform_delegate_cocoa.h
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/cocoa/extensions/extension_action_platform_delegate_cocoa.mm
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/extensions/extension_action_platform_delegate.h
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/extensions/extension_action_view_controller.cc
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/views/extensions/extension_action_platform_delegate_views.cc
[modify] https://crrev.com/98f7b6d97ccaa3c469319a0e1bbc051885847d0b/chrome/browser/ui/views/extensions/extension_action_platform_delegate_views.h