Spawned from http://cbrug.com/812056#c21

IMO, It feels a bit clunky to use a WebContents context menu for a system app. I think we can do better in the ChromeOS Files App.

Support for text-editing commands aside (see http://cbrug.com/812056#c21 ). There are still many bugs:
 - if the window is too short, half the items are missing and there is no way to scroll the menu ( Issue 847794 )
 - font styles and padding are different to menus elsewhere in ChromeOS
 - the menu doesn't dismiss unless you click on the webcontents, and the behaviour is incorrect for a menu (click is not suppressed, for example. touching to dismiss will open a file).
 - other standard menu behaviours are not implemented. E.g. mnemonics (pressing the letter corresponding to the menu item)
 - menu is not properly accessible (e.g. when running ChromeVox, the a11y cursor does not shift to the menu when opened)
 - menu can not be invoked via touch-dwell
 - (assuming it could, I expect it does not have larger targets/padding when invoked via touch)
 - holding-down the click that invoked the menu and releasing it after dragging to a menu item does not work

All of these are resolved by using "real" context menus

The files app is an extension.. There is already machinery allowing extensions to add items to the context menu (it may need improvements). But we can also do a lot more by adding a extensions::VIEW_TYPE_FILES_APP, and disable items we don't want from the standard context menu via an override of ContextMenuContentType::SupportsGroup(). There's already a bunch of extension-specific stuff in ContextMenuContentTypeFactory::CreateInternal

chrome.contextMenus.create works in a packaged-app context nicely - (I toyed with it a bit here a long time ago - https://github.com/tapted/foreman-task-tracker/blob/master/src/foreman.js#L135 )
 

Spawned from  http://crbug.com/812056#c21 

IMO, It feels a bit clunky to use a WebContents context menu for a system app. I think we can do better in the ChromeOS Files App.

Support for text-editing commands aside (see http://cbrug.com/812056#c21 ). There are still many bugs:
 - if the window is too short, half the items are missing and there is no way to scroll the menu ( Issue 847794 )
 - font styles and padding are different to menus elsewhere in ChromeOS
 - the menu doesn't dismiss unless you click on the webcontents, and the behaviour is incorrect for a menu (click is not suppressed, for example. touching to dismiss will open a file).
 - other standard menu behaviours are not implemented. E.g. mnemonics (pressing the letter corresponding to the menu item)
 - menu is not properly accessible (e.g. when running ChromeVox, the a11y cursor does not shift to the menu when opened)
 - menu can not be invoked via touch-dwell
 - (assuming it could, I expect it does not have larger targets/padding when invoked via touch)
 - holding-down the click that invoked the menu and releasing it after dragging to a menu item does not work

All of these are resolved by using "real" context menus

The files app is an extension.. There is already machinery allowing extensions to add items to the context menu (it may need improvements). But we can also do a lot more by adding a extensions::VIEW_TYPE_FILES_APP, and disable items we don't want from the standard context menu via an override of ContextMenuContentType::SupportsGroup(). There's already a bunch of extension-specific stuff in ContextMenuContentTypeFactory::CreateInternal

chrome.contextMenus.create works in a packaged-app context nicely - (I toyed with it a bit here a long time ago - https://github.com/tapted/foreman-task-tracker/blob/master/src/foreman.js#L135 )