Please find the screencast

Deleted: Actual_focus (1).mov 2.0 MB

Actual_focus (1).mov 2.0 MB Download

This requires full keyboard navigation to be enabled. That should have been mentioned in the initial report. 

I'm inclined to say that this is WAI. Focus usually proceeds to containers first and then their contents, and the omnibox "contains" the decorations. Focusing the padlock (and left decorations in general) first would make the focus order closer to left-to-right, but I think outer-before-inner should take precedence over that.

Does anyone have strong opinions either way?

Not strong, but after trying it, the current behavior *does* seem surprising. Try focusing the omnibox with cmd+L, then hitting tab — the lock/search icon getting focus feels weird to me.

If I had to guess how to focus that icon, I would probably hit cmd+L followed by shift+tab.

…OK, so just tabbing through the top bar it doesn't feel *as* unexpected, but I don't think the alternate behavior would be unexpected in that situation either.

Above issue is reproducible on Latest Canary Version:54.0.2787.0 (Official Build) 229c5186fc07b397ec91db5f03367db2cf06f9a9-refs/heads/master@{#403602}

There's no need for further repros of this; right now it's behaving as designed, and we're discussing whether the design ought to be different.

@ellyjones: Hey, can you please provide an update on the above issue as per your comment#7 ?

I really appreciate your help.

Thank you!

I consulted with some UI/a11y folks and it seems the consensus is that left-omnibox-right is the proper focus order, so I'll work on fixing this in the next couple of days.

I don't think this is a regression though since those elements were never keyboard-focusable before.

@ ellyjones: As per your above comment, can you please land your fix and let us know if this is a blocker issue. M53 is going to be pushed to Beta soon.

Thanks.!

Okay, a fix is landed in trunk now: https://codereview.chromium.org/2155233002/.

Requesting merge to M53.

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

commit bd2ba8d0939223348e7b01d5c0398fde744fb72f
Author: ellyjones <ellyjones@chromium.org>
Date: Tue Jul 19 20:58:46 2016

omnibox: make decorations non-focusable for now

The key view loop is messed up for these decorations, as described in
 https://crbug.com/623883 , so let's make them non-focusable pending a real fix.

BUG= 623883 

Review-Url: https://codereview.chromium.org/2155233002
Cr-Commit-Position: refs/heads/master@{#406376}

[modify] https://crrev.com/bd2ba8d0939223348e7b01d5c0398fde744fb72f/chrome/browser/ui/cocoa/location_bar/location_bar_decoration.mm

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Unable to repro this issue on MAC (10.11.5) for Google Chrome Canary Version - 54.0.2802.2 

Screen-recording is attached.

Thank you.

Deleted: 623883.mov 2.6 MB

623883.mov 2.6 MB Download

@ellyjones: Could you please resolve this issue as Fixed/Verified as per the comment #14.

Thank you.

Please merge to M53 branch 2785 ASAP. Thank you.

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

commit a07d9c1793708519b7ffb1ecf776e4a0deb3b9f3
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Fri Jul 22 14:52:50 2016

omnibox: make decorations non-focusable for now

The key view loop is messed up for these decorations, as described in
 https://crbug.com/623883 , so let's make them non-focusable pending a real fix.

BUG= 623883 

Review-Url: https://codereview.chromium.org/2155233002
Cr-Commit-Position: refs/heads/master@{#406376}
(cherry picked from commit bd2ba8d0939223348e7b01d5c0398fde744fb72f)

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

Cr-Commit-Position: refs/branch-heads/2785@{#296}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/a07d9c1793708519b7ffb1ecf776e4a0deb3b9f3/chrome/browser/ui/cocoa/location_bar/location_bar_decoration.mm

Fix has been merged to 2785.

Verified this issue on Mac OS 10.11.5 using chrome latest Dev M53-53.0.2785.30 by following steps mentioned in the original comment. Observed the Tab focus is seen on ‘Search’ icon as expected. Hence adding TE-Verified label.

Deleted: 623883.mp4 286 KB

	623883.mp4 286 KB View Download

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

commit 88246ce0f7ae1b9a65c1056e9f2c09fe9e0244fe
Author: ellyjones <ellyjones@chromium.org>
Date: Wed Apr 26 17:25:50 2017

cocoa: allow omnibox decorations to become key

Originally, this behavior was disabled because leading decorations were
appearing in the key view loop after the omnibox itself, which led to
an unintuitive tab order. This change:

1) Allows omnibox decorations to become key when they are accepting mouse clicks
   again
2) Mangles the automatic key view loop slightly so that leading decorations
   appear before the omnibox in the tab order

BUG= 623883 

Review-Url: https://codereview.chromium.org/2839893003
Cr-Commit-Position: refs/heads/master@{#467363}

[modify] https://crrev.com/88246ce0f7ae1b9a65c1056e9f2c09fe9e0244fe/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_cell.h
[modify] https://crrev.com/88246ce0f7ae1b9a65c1056e9f2c09fe9e0244fe/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_cell.mm
[modify] https://crrev.com/88246ce0f7ae1b9a65c1056e9f2c09fe9e0244fe/chrome/browser/ui/cocoa/location_bar/location_bar_decoration.h
[modify] https://crrev.com/88246ce0f7ae1b9a65c1056e9f2c09fe9e0244fe/chrome/browser/ui/cocoa/location_bar/location_bar_decoration.mm
[modify] https://crrev.com/88246ce0f7ae1b9a65c1056e9f2c09fe9e0244fe/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm