Peter, do you happen to know who owns this? Just asking since it's attached to the omnibox.

I do not know.

This might be WAI or could get fixed.

Permission prompt you mentioned would grab focus and deactivate browser window. So I guess "ctrl+tab" "ctrl+w" need browser window activated to perform action.

For "ctrl+t", it doesn't need the activation condition, as you can press "ctrl+t" to open new window on empty desktop.

We could fix it by performing those actions on transient parent if activation window is transient.

sky@, is this WAI or a bug in your opinion?

Thanks for digging into this, Joe!

It seems to me that the current behavior is unintentional, or at least inconsistent. If I open an incognito window and do a location-dependent Google search like [pizza] via the omnibox, I'm unable to close the tab with Ctrl+W, but if I hit Alt+Tab to focus another window and then Alt+Tab again to focus the incognito window again, Ctrl+W now starts working.

Performing these actions on the transient parent makes sense to me, but I'm curious about what Scott thinks. :-)

I agree it would be nice to have keyboard shortcuts continue to work even when a prompt takes focus. I can't remember if it was hard to do this because of bubbles being separate windows. sky/tapted would know. 

I think this is Issue 319109, which affects CrOS, Windows and Linux, we can dupe into that unless we want something specific for permissions bubbles.

On Mac, accelerators work with permissions bubbles (see  Issue 603881 ), and the permissions bubbles use toolkit-views there. However, I haven't looked into getting the same thing working in  mac_views_browser (where it's not working, but might be a simple fix).

There's an old external contribution in https://codereview.chromium.org/2604793002/ which might be able to be cleaned up for a general solution (I didn't really like the approach..). Key dispatch on Mac will always be more complicated since it needs to go through the mainMenu bar (where users can customize their keyboard accelerators!). But r447864 (which fixed the current bubbles on Mac) allows a child views::Widget to hook in neatly (IMO).

Note there's also Issue 775717 -- an a11y bug.

re #c6: I've noticed some inconsistency on ChromeOS too (http://crbug.com/319109#c4)

Yes, sounds like this is a duplicate of that (2013 :-/) bug.

The permission bubble case seems much worse to me than e.g. bookmark bubbles, since arbitrary sites can open them to block Ctrl+W, but that's already called out on the other bug too.