It works in Linux but breaks in Windows.

Bisected to 0df5837131a55ff6560a80b181ef90e620ea8092 = https://crrev.com/1625313002 by mohsen@chromium.org
"Remove MenuMessagePumpDispatcher"
Landed in 50.0.2633.0

wenrui@ Thanks for the issue.

Tested this issue on Windows 10 and & on the reported version 66.0.3359.139 and the latest Canary 68.0.3419.0 and unable to reproduce the issue by following the steps given in the original comment.

Able to navigate the context menu of the app with keyboard on right clicking on the tray icon.
Attached is the screen cast for reference.

Request you to retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks..

Deleted: 837520.mp4 1.6 MB

	837520.mp4 1.6 MB View Download

By tray icon I mean the chrome icon in the bottom right corner area, not the task bar. Would you please try it again?

susan.boorgula@ you didn't click in the *tray* icon menu, you clicked the taskbar icon context menu, which is not related to the issue.
The tray icon is shown in the bottom right corner, see the attached screenshot.

Deleted: tray.png 14.3 KB

	tray.png 14.3 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Just in case, here's the tutorial:
https://www.ghacks.net/2015/03/11/manage-and-display-system-tray-icons-in-windows-10/

Able to reproduce the issue on Win-10 using chrome reported version #66.0.3359.139 and latest canary #68.0.3430.0. Issue is not seen in OS-Linux.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Hello,

This issue is impacting the Slack desktop app for Windows, which is built using Electron. I see this bug has yet to be triaged. Any update from the Chromium team with respect to the complexity involved as well as the turnaround time for a fix would be greatly appreciated.

Thanks,
Todd

I think this is the code. I'm not sure why this would be different than any other menu.

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/status_icons/status_icon_win.cc?sq=package:chromium&g=0

The CL found in #c2 doesn't include status_icon_win.cc so I doubt it's relevant.

I was able to reproduce this after a fashion in Chromium on Windows 10, with the Hangouts app. The context menu only has one item, but hitting return doesn't do anything, and the menu doesn't seem to have focus. However, I don't think status_icon_win is the relevant code, since the menu is opened by message_center::MessageViewContextMenuController, from a ToastContentsView.

I'll try to dig into this a bit more.

Both the tray icon menu and the toast notification issue are because the menu doesn't get keyboard focus. I tried creating a widget in status_icon_win, creating the menu with the widget, and calling Show on the widget, and it fixes the issue. I'm not sure why the menu code itself doesn't take focus in this case.

@sky - the issue with the status_icon_win context menu not getting key events seems to be because the menu is created without a parent widget. 

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/status_icons/status_icon_win.cc?l=66

In that case, the menu_host never gets activated, so the menu hwnd never gets keyboard focus. From what I can tell, menu widgets never get activated, but rely on the parent widget having focus, and routing key events to the menu.  I've found two ways of fixing this:

1. In MenuHost::InitMenuHost, if the parent widget is null,  set params.activatable = Widget::InitParams::ACTIVATABLE_YES, and at the end of  MenuHost::ShowMenuHost, if owner_ is null, call Show(). 

or
2. In status_icon_win, create a TYPE_POPUP Widget to pass to RunMenuAt, and then after calling RunMenuAt, call Show() on the widget.

Do you have a preference between these 2, or can you suggest a better way of fixing this? #1 has the advantage of fixing this for any other code that does this, and #2 seems like a workaround for a bug in the menu code. But, I think the status_icon_win code is an outlier in creating a menu with no parent widget or view and a null, and perhaps that shouldn't be allowed?

The bug itself is easy to reproduce on Windows - just run Chrome, and right click on the Chrome icon in the window tray at the bottom right of the windows task bar. That context menu doesn't see key strokes.

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

commit 1dc120ad70c9984e5580546f89818ea2477055a6
Author: David Bienvenu <davidbienvenu@chromium.org>
Date: Mon Jul 30 15:15:34 2018

Fix keyboard access for windows system tray menus.

The fix is to make menus without a parent widget take focus when run.

Bug:  837520 
Change-Id: I2dd286e4b10051c8a4fa460f1187eef8292cf517
Reviewed-on: https://chromium-review.googlesource.com/1142201
Commit-Queue: David Bienvenu <davidbienvenu@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579041}
[modify] https://crrev.com/1dc120ad70c9984e5580546f89818ea2477055a6/chrome/browser/ui/views/menu_interactive_uitest.cc
[modify] https://crrev.com/1dc120ad70c9984e5580546f89818ea2477055a6/ui/views/controls/menu/menu_host.cc