Holding down the shortcut also works (rapidly changes between user) once the key repeat kicks in.

Oshima wondered on the code review if those two shortcuts should be moved to the Search key as well. 

Currently, I just added them to the "Reserved Actions" https://code.google.com/p/chromium/codesearch#chromium/src/ash/accelerators/accelerator_table.h&q=kReservedActions&sq=package:chromium&type=cs&l=218.

What do you think?

I spoke to tbuckley@ offline, and he's not sure if multiprofile shortcuts are worth moving to the Search key. 

I thought we want to shift to search key when we found conflict, to avoid stealing key from apps, not really about the importance of the chromeos shortcuts?

I also believe that, for consistency, if the shortcut is important to us, then let's move it to Search.

BigTop says there's no conflict here, but my own testing contradicts that.

Any idea why this happens in-a-window and not in-a-tab? Is that a bug or a feature?

I'm also curious why this only happens when set to open in a window.

Is that only on M52? I can't repro on M53 by the way. Not even when the Inbox window is full screen!

Yes, 52.0.2743.19 (Official Build) dev (64-bit)

So does that mean that Inbox does not prevent users from switching profiles in M53? If so, it sounds like this issue is fixed.

sgtm.

Just as an reminder, we should not blindly steal key sequence from apps. 
App does not necessarily mean chrome apps. If there is an Windows app that replies on this shortcut, such change will make it impossible to use it on Remote desktop.

Ok, I spoke to michaelpg@ and found out that "Keyboard shortcuts" must be enabled from Inbox settings to be able to repro. 

I can now repro on M53.

It must be consumed somehow in Inbox. The RenderWidgetHost is receiving an event acknowledge state of value = INPUT_EVENT_ACK_STATE_CONSUMED.

What shall we do here?

I'm a bit confused -- how is Inbox consuming it in windowed mode but not in tabbed mode? I'd be very surprised if it is doing anything differently between the two, or can even tell the difference.

To be clear, it sounds like there are two issues here:
1) Why does Inbox intercept the switch-user shortcuts when set to open-in-a-window but not open-in-a-tab?
2) Should we prevent websites from ever intercepting the switch-user shortcuts? This would require moving those shortcuts to use Search (if we want to be consistent).

Re #1, @afakhry can you look into what's causing that?

Re #2, I'm open to moving the shortcuts. However, Search+. is already taken by "Insert".

When Inbox is started as a window, the BrowserView thinks it's an app, and hence doesn't pre-handle the shortcut key and then it's sent to the renderer: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/views/frame/browser_view.cc&q=BrowserView::PreHandleKeyboardEvent&sq=package:chromium&type=cs&l=1389

Here is the summary of how shortcuts priority is controlled.

https://cs.chromium.org/chromium/src/ash/accelerators/accelerator_table.h?rcl=0&l=18

We do our best to try to give more control to apps, and it's based on our motto  "content first". Search key modifier is an exception and we can take it if necessary. (i believe)

I suspect we should also open a bug on Inbox because it shouldn't be handling this shortcut anyway.

Yes, chrome has no way to know why the event was consumed, so if it didn't use it, then it shouldn't consume it.

I'm changing it back to "Assigned" until we decide how to move forward. Fix Inbox and call it the day? Or fix Inbox as well as moving the shortcuts to use Search?

I vote for "fix Inbox". I'm still holding out hope that Ctrl+Alt+. makes it to desktop Chrome....

The correct action here appears to be "fix inbox"

The fix here is for inbox to stop consuming shortcuts it doesn't need. Internal bug filed.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Internal bug b/29412463 has been fixed. I confirmed that it's possible to switch user profiles using the shortcuts when Inbox is opened in Window mode.

Marking this no-op bug as verified to remove from our queue