Tested the issue on latest stable 61.0.3163.79 and latest canary 63.0.3215.0 using Ubuntu 14.04,Windows 10 and Mac 10.12.1 and is reproducible with steps mentione in comment#0 i.e Default focus is not seen on password bubble for first time. But after clicking it manually we are seeing focus on it.

This issue is seen form 50.0.2661.66 build. So considering this issue as Non-regression and marking as Untriaged.

This seems to be intended from comment#8 of https://bugs.chromium.org/p/chromium/issues/detail?id=510718#c8

Vasilii, I think that you have an open bug for this, right? Can you dedupe this?

This is actually used to work on Windows. The password icon was focusable. One could use TAB to move the focus to it which immediately focused the bubble and now the user can everything there with the keyboard. The bug was introduced in r390244. ManagePasswordsIconViews calls SetFocusBehavior(FocusBehavior::ALWAYS) in the constructor. However, that value is immediately overwritten in BubbleIconView::Init().

Now the question to the UX team is if we want to change the behavior.
Max:
The password bubble is opened without focus (expected). The previous behavior was that one could use TAB to get into the bubble. The the focus was there until the bubble was dismissed. Now the tab order excludes the password bubble and therefore it's not accessible. Do we want to restore the previous behavior or keep the current one or to invent something new?

I think we need a general solution from our a11y experts on how to deal with bubbles that don't take focus.


> The previous behavior was that one could use TAB to get into the bubble.

Is this weird? Tab to navigate between different windows doesn't seem like normal behaviour on any platform. I'm pretty sure that could never have happened on macOS. I'm also unsure whether it worked on Windows except under XP/RDP where bubbles were not "top level" windows, but just aura::Windows that clip to their parent window.

While inside a popup, it would also be peculiar to press <tab> to leave the popup. That should cycle between controls in the window. If <tab> could get you out the same way it got you in, then most bubbles would just dismiss themselves since they lost focus.

On MacOS, a VoiceOver user can press VO+F2+F2 to bring up the window list - bubbles are included there, and can be switched to. However the bubble window doesn't appear in the mainMenu->Window list, and can't be switched to with the regular window cycle command, Cmd+` for non-VoiceOver users.

If a bubble doesn't take focus when it's shown it's going to be tough for a11y users to use.

Question for a11y experts:
 - Are there other conventions for keyboard navigation that Chrome should be using to focus child windows?
 - Should we adopt Tab-from-omnibox ? (what's the plan for tab-within-popup?)
 - Does Chrome need something specific like Announcement + "Press <custom keystroke> to focus popup."
   -> do we communicate this to non-voiceover keyboard users somehow
 - Should we just put popups in the Cmd+` (and Windows-equivalent) window cycle lists?

Deleted: Screen Shot 2017-09-19 at 10.50.14.png 210 KB

	Screen Shot 2017-09-19 at 10.50.14.png 210 KB View Download

hwi@ is the right person for those questions, I think.

I'll look into this next week (I'm attending a team convergence). 

Since Hwi mentioned she'll take this, I am changing the status to Assigned and removing label Needs-Triage-M61.  

Although it's required to learn and remember shortcuts/hotkeys, the password popover can be accessed via keyboard.
Please let me know if the following addresses the reported issue. 

Here's the current availability for keyboard navigation to the password popover dialog. 

Windows 10 (sorry I wasn't able to test Win 8. If anyone can help test on Win 8, that will be helpful):
- F6 moves the focus to Omnibox
- And, hitting F6 again moves the focus to the password popover while the popover is open
- Tabbing moves the focus within the popover (focus trapping is intended)
- While the popover is closed, F6 -> Tab (to the key icon) -> Space opens the password popover

Chrome OS: 
- Ctrl-Back (or multiple of it) moves to the focus Omnibox
- And, Tab moves the focus to the password popover while the popover is open
- Tabbing moves the focus within the popover (focus trapping is intended)
- While the popover is closed, Ctrl-Back (or multiple of it until Omnibox is focused) -> Tab (to the key icon) -> Space opens the password popover

OSX:
- Turn on Full Keyboard Access
- Ctrl-L moves the focus to Omnibox
- And, Esc closes Omnibox suggestion and the password popover (intended, although not ideal)
- Tab moves the focus to the key icon
- Space opens the password popover

There's a room to add clear and consistent keyboard navigation for popovers in general, which have been being looked into separately.

Thanks!

As a11y "expert," I recommend following WAI ARIA authoring practices for a modal dialog box (https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal). When the box opens, focus is automatically set to either the dialog box itself or the first interactive control (e.g., button). Use the correct labeling/description recommendations, as outlined in the guidelines. Tabbing stays inside the box until it is closed by the user. Prevent screen reader access to everything below the box using aria-hidden="true."

re: c10

Hi jbirdgrant@, 

Thanks for the recommendation and the pointer for the screenreader navigation. 

A tricky part is that the password save prompt is a non-modal dialog. The password save prompt uses a non-modal (not a modal) with an intention to offer a help without blocking page navigation. I'll keep an eye on the development of http://w3c.github.io/aria-practices/#dialog_nonmodal.

The current idea to improve the non-modal dialogs in Chrome desktop context is that 1) they need to be announced when appearing, 2) they should not interrupt/block the page navigation when they appear, 3) there should be an efficient way to navigate to them, 4) when to announce, e.g. before other announcements or after, is up to the feature. I appreciate suggestions on this. 

re: c9
Separately, going back to the original reporting, I'm also interested whether or not the original issue was about *non-screenreader* keyboard navigation, and if so, whether c9 addresses the issue. If the original issue was about screenreader navigation, we should clarify the bug description and I can continue to follow up on the non-modal screenreader behavior. 

Hello,

I'm looking to get this assigned either as a bug or as a feature request. Please kindly let me know if the original issue still reproduces in light of this information. 

If the issue still reproduces, I will get this routed to an engineer. 
If the issue does not reproduce, I will change this issue to a feature request and track accordingly. 

Thanks,

Laura 

This is a bug and should be fixed for keyboard users. I can still reproduce this issue in Chrome browser on windows 8 machine. 

Hello,

I'd like a little more detail. Please let me know on which number step the process is failing for you when you perform these steps and what the failure behavior looks like exactly. 

1. F6 moves the focus to Omnibox
2. Hitting F6 again moves the focus to the password popover while the popover is open
3. Tabbing moves the focus within the popover (focus trapping is intended)
4. While the popover is closed, F6 -> Tab (to the key icon) -> Space opens the password popover

Thanks,

Laura 

Chrome 65.0.3291.1 (Official Build) canary SyzyASan (32-bit) (cohort: ASAN)
NVDA: 2017.4

Keyboard navigation with f6 does work to get to the save password option, but when this option becomes available, NVDA does not announce that it is there or how to access it. Users will have to know when it appears and how to get there before being able to make use of this feature.

Google Chrome 65.0.3294.2 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 1607 Build 14393.1770

This is in reference to the password save dialog in Windows in the attached screenshot. I can repro that I am not able to tab into it and it is not announced as being there. 

Deleted: 764918.png 71.6 KB

	764918.png 71.6 KB View Download

Peter, is this something the Harmony team can help with?

+bsep@ FYI. I don't think this is something that we can fix as part of the first-step Harmony effort (due for M65). It's possible that I'll be looking into several accessibility bugs after Harmony (not part of Harmony), but it's not set in stone yet.

So the answer is "likely yes" if it's less time critical and "likely no" if it's very time critical. We're swamped for M65 and possibly straggling dialogs as part of M66. No promises though, I haven't been assigned post-Harmony work.

Out of scope for Harmony. It's not clear to me what the scope of changes here are, but if you come across low-hanging fruit while working on the password dialog feel free to address it.

Google Chrome	66.0.3355.4 (Official Build) dev (64-bit) (cohort: PGO)

Steps to reproduce:
# Go to https://rsolomakhin.github.io/autofill/
# Enter any user name and password (content gets sent to example.com so don't make it anything real)
# Invoke submit
# Popover appears anchored to the right side of the Omnibox

To get to that popuover via keyboard, you need to first press F6 to get into the context of the Omnibar tab cycle. Then, you press tab to put focus on the popover. Then you use arrow keys to navigate around the buttons. 
 

I'll repurpose this bug to cover more than it was filed for. I'll see if I can come up with a good proposal.

Another interesting point. There are two keyboard shortcuts to take you to the Omnibox. If you use F6, it puts you in the Omnibox where the context is that tab will cycle you around the Omnibox, the bookmark icon, the extensions, the menu, etc. If you instead use ctrl + l, it will put you in the Omnibox in the same way as if you had just landed on it via a new page - pressing tab will bring you down into the main page context. 

Google Chrome	67.0.3363.0 (Official Build) canary (64-bit)
Revision	0
Platform	10464.0.0 (Official Build) canary-channel samus
Firmware Version	Google_Samus.6300.276.0

alt + shift + a nothing happens
alt + shift + d nothoing happens

From what I can read IDC_FOCUS_INACTIVE_POPUP_FOR_ACCESSIBILITY as alt + *shift* + A works, but is undocumented and is not available on Mac or ChromeOS. :(

I deleted comment 31 since I used the incorrect key combo.
Google Chrome	67.0.3364.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Steps to reproduce:
# Go to https://rsolomakhin.github.io/autofill/
# Enter any user name and password (content gets sent to example.com so don't make it anything real)
# Invoke submit
# Popover appears anchored to the right side of the Omnibox

alt + shift + a puts focus on the save button, you are able to tab around in that dialog

alt + shift + d does nothing

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

commit 242f4a44e312daf33570890113b25543ca290105
Author: Peter Boström <pbos@chromium.org>
Date: Mon Mar 12 22:59:44 2018

Focus inactive bubbles in pane-cycle command

Makes unfocused popover dialogs keyboard accessible on non-MacOS where
F6 is used to cycle between different panes.

Follow-ups changes that are necessary are:

* Choose and utilize a different (non-function key) on MacOS.
* Update keyboard shortcut help documentation so users who search the
  web for "chrome dialog keyboard shortcut" has a chance of finding it.

This intentionally locks user focus inside the inactive bubble instead
of adding it to the pane cycle. Users who intend to use pane cycling
will need to accept or dismiss the dialog (normally using ESC) before
continuing pane cycling.

Bug:  chromium:764918 
Change-Id: Ib0144c9f914b63758f23454547c26907747f5939
Reviewed-on: https://chromium-review.googlesource.com/956528
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542644}
[modify] https://crrev.com/242f4a44e312daf33570890113b25543ca290105/chrome/browser/ui/views/frame/browser_view.cc

leberly@: F6 should be usable in the next Canary, outside of Mac. Please help verify if you can. It lets you get to all bubbles that are attached to the location bar (there are a few that are not, unfortunately).

I think Mac's tab order (with full keyboard access enabled) is significantly better than the one we have in Windows / ChromeOS. Longer term I would like all OSes to adopt it (will possibly happen as part of MacViews), that way Windows' tab order is less complicated, doesn't require knowledge of F6 and can still get to the dialog through location-bar icons (like F6 -> tabbing on Windows today).

Popover outside of the location bar will need to be addressed separately.

Able to reproduce the issue on reported version hence verifying the fix on latest canary 67.0.3370.0 using Windows 10 and Ubuntu 14.04.

On hitting alt + shift + a focus is seen on save button of password bubble, on hitting alt + shift + d nothing happened, on hitting F6 and tab, selected key icon and able to navigate to all fields in password bubble. Attaching screencast of same.

Hence verified the fix on Linux and Windows. Adding TE-Verified labels.

Thanks!

Deleted: 764918.mp4 893 KB

	764918.mp4 893 KB View Download

This is at least slightly better on non-Mac platforms right now. I filed b/75023807 (internal only) to have the documentation updated. I have no immediate plans to get this into a better state so marking as Available. I don't think this is easily keyboard accessible yet, F6 is hard to guess.

 Issue 812278  has been merged into this issue.

 Issue 805723  has been merged into this issue.

Issue 775717 has been merged into this issue.

Summary after de-duping password popover bugs:

CRBug.com/775717 and  CRBug.com/775711  are both related to popovers but not password specific so they are marked as blocked by this bug.

 crbug.com/812278  Dupe report from user: 
1. Install NVDA on Windows
2. Go to page that triggers the "Do you want Google Chrome to save your password for this site?" dialog
Expected: NVDA lets me know there is an alert.
Actual: There seems to be no way for screen reader user to access this dialog without mouse
Google version: 64.0.3282.167

 crbug.com/805723  Dupe report from developer: 
a11y Passwords page: screen reader not reading after dismissing view password Windows dialog
Google Chrome 66.0.3329.1 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version 1607 Build 14393.2007
NVDA 2017.4
JAWS 2018.1801.18 Private Beta 

This was reported to me by a developer @nektar so I'll note where his experience differs from mine. 

Steps to repro:
# Launch JAWS
# Navigate to chrome://settings/passwords or Chrome > Settings > Manage Passwords 
# Navigate to any saved password and invoke the "view password" button, note that JAWS says Show password Button without issue. 
# Windows OS prompt appears. It appears as a modal when using Chrome, blocking accessing other parts of Chrome browser. However, I am able to shift + tab to other parts of the OS such as other programs and use them without issue. Unlike a permissions prompt, this prompt doesn't block everything in the OS. 

For me, the prompt was read automatically when it appeared, but it did not say the text at the top such as "Windows Security". After that, I was unable to access the content in the prompt except for tabbing to the "more options", OK, and Cancel buttons. Arrow keys only navigated between the OK and Cancel buttons. 

For @nektar, the prompt is not read at all. He was unable to tell that this a Windows prompt, not a Chrome prompt. 

# Enter your Windows credentials, accept the dialog by pressing enter. 
# Focus returns to the Chrome passwords page, now with the password visible. 

With the latest version of JAWS, the content in Chrome is read. The last time I tried this with a slightly older version of JAWS, nothing was read. Note that JAWS reads it as static text, not as an edit box that uses forms mode. JAWS said "read only edit" and forms mode is off. I can navigate across it with the arrow keys to read it character by character.   

# Repeat all the above steps with NVDA 
On the Windows dialog, all content is spoken including the "Windows Security" text at the top.

Once the Windows dialog is read, I'm not able to navigate to get that content to read again with arrow keys or tabbing. 

When I am navigating across the newly uncovered password, NVDA sees it as a text entry field and goes into forms mode. To read the password character by character, I need to go into focus mode and then navigate across it with the arrow keys.   

I'm going to take this on.

We got support from rpop@ and markchang@ to implement this behind and flag, then take it to UI review and play with it.

Specifically, the plan is that any non-modal popover will be part of the tab order so there's an intuitive way to focus it with the keyboard if it's not initially focused or subsequently loses focus.

Thanks!

Note that there are more non-modal popovers than ones accessible through the location bar. This method is incomplete for this reason: https://cs.chromium.org/chromium/src/chrome/browser/ui/views/location_bar/location_bar_view.cc?type=cs&q=location_bar_view.cc&sq=package:chromium&l=658

I think site permissions might be an example of a non-modal bubble not attached to the location bar.

Clarifying: BrowserView::FocusInactivePopupForAccessibility() is incomplete for this reason, not the LocationBarView part of it necessarily.

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

commit 5d26d2ba2f024f7e043a9f759212ad5564715f78
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Mon Apr 23 23:50:43 2018

Use enums as arguments to FocusSearch to improve readability.

Also replace NULL with nullptr throughout FocusManager and
FocusSearch.

Bug:  764918 
Change-Id: Ic90607c470130ac53375b26e601c1226c34a501a
Reviewed-on: https://chromium-review.googlesource.com/1024990
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552907}
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ash/login/ui/lock_contents_view.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ash/shelf/shelf_view.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ash/shelf/shelf_widget.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/chrome/browser/ui/views/payments/payment_request_sheet_controller.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ui/views/accessible_pane_view.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ui/views/focus/focus_manager.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ui/views/focus/focus_search.cc
[modify] https://crrev.com/5d26d2ba2f024f7e043a9f759212ad5564715f78/ui/views/focus/focus_search.h

Would it be possible to have an event fire on creation of these popovers? I'm making an extension for Chrome that will play sounds for certain browser events. I'd like to be able to play a sound when these types of popovers occur, but I don't think there's an event I can listen for.

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

commit 2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Thu May 17 20:18:00 2018

Add support for focus traversing into anchored dialogs.

Make it possible for focus to traverse into a dialog that's anchored at
a particular View by setting a property on the anchor View, and setting
FocusTraversableParent on the dialog.

This change introduces the property and adds support in FocusManager and
FocusSearch, and adds unit tests, but doesn't use the view property in
any views. There should be no user-visible change.

Bug:  764918 
Change-Id: I244774a18cdf4e40ac7cdd610349aec3855cb4b2
Reviewed-on: https://chromium-review.googlesource.com/1015291
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559656}
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ash/login/ui/lock_contents_view.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ash/shelf/shelf_view.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ash/shelf/shelf_widget.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ash/system/user/user_view.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/chrome/browser/ui/views/payments/payment_request_sheet_controller.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/accessible_pane_view.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/bubble/bubble_dialog_delegate.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/bubble/bubble_dialog_delegate.h
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/focus/focus_manager.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/focus/focus_manager_unittest.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/focus/focus_search.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/focus/focus_search.h
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/view_properties.cc
[modify] https://crrev.com/2c41f7908261f8f2c5fa98f2fb5ed8b591735f8a/ui/views/view_properties.h

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

commit 27af8e0a6de92fc683661ae453ed7a2a1edc7c6e
Author: Daniel Bratell <bratell@opera.com>
Date: Tue May 22 06:59:21 2018

[jumbo] Declare BubbleDialogDelegateView template specialization

BubbleDialogDelegateView has a specialization of view properties
so declare it to be sure the compiler doesn't get upset about
using properties before it knows about the specialization.

Bug:  764918 
Change-Id: I55b70dc3dacfdcd5eb466cfcde234090573d2bfa
Reviewed-on: https://chromium-review.googlesource.com/1067346
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Daniel Bratell <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#560502}
[modify] https://crrev.com/27af8e0a6de92fc683661ae453ed7a2a1edc7c6e/ui/views/view_properties.h

As there are no steps in comment#51 to verify this issue, checked the steps from duplicate  issue 812278  which is in comment#44.

1. Installed NVDA on Windows
2. Logged into gmail.com which triggered "Do you want Google Chrome to save your password for this site?" dialog but NVDA didn't read this as there is no focus on this dialog.
3. Used alt+shift+a , focused save button and read "Do you want google Chrome to save your password? ...." 

Observing same behavior in build without fix 66.0.3359.181 and latest canary 68.0.3438.0. Hence adding Needs-Feedback label.

@bratell: Please check the steps and let us know if we miss anything? Please help in verifying the fix.

Thanks!

This bug isn't marked as Fixed and comment 51 is not a functional change. I don't think there's anything to test here. 

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

commit c4ce69ce4b0de355ef27058fb5247bcc315ccd80
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Fri May 25 17:22:07 2018

Enable focus traversing into anchored dialogs.

As a follow-up to http://crrev.com/c/1015291, this change makes it so
that all bubbles with an anchor view are now part of the focus order of their
anchor view.

Bug:  764918 
Change-Id: I76fd7b5d8c8c5c10d5f7ff9c0278f6207f4db4d6
Reviewed-on: https://chromium-review.googlesource.com/1025372
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561930}
[modify] https://crrev.com/c4ce69ce4b0de355ef27058fb5247bcc315ccd80/ui/views/bubble/bubble_dialog_delegate.cc
[modify] https://crrev.com/c4ce69ce4b0de355ef27058fb5247bcc315ccd80/ui/views/focus/focus_manager.cc
[modify] https://crrev.com/c4ce69ce4b0de355ef27058fb5247bcc315ccd80/ui/views/focus/focus_manager_unittest.cc
[modify] https://crrev.com/c4ce69ce4b0de355ef27058fb5247bcc315ccd80/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc

Thanks for working on this.
Chrome: 69.0.3444.0 (Official Build) canary (64-bit) (cohort: Clang-64)
I tested with permission.site and I was able to tab out of the bubble and shift tab back in.

The only way to access bubbles other than tabbing from web content is to press alt+d or ctrl+l and then press tab.
They cannot be tabbed to from the toolbar and are not in the f6 cycle.

If bubbles are somehow attached to each other, it would make sense that f6 should access them. Not as individual bubbles, but as the area where tabbing between bubbles works.
If not, maybe tabbing from the toolbar would make sense.

I noticed that pressing f6 when a permissions bubble has focus does not navigate to the omnibox.

Flipping to verified based on comments from dsexton above and after confirming with him today. 

If further problems appear, please open a new bug and reference this one, thanks!

Also related to https://bugs.chromium.org/p/chromium/issues/detail?id=764918