Begin whitelisting specific extensions for global key registration.

chrome/browser/extensions/api/commands/command_service.cc

Index: chrome/browser/extensions/api/commands/command_service.cc
diff --git a/chrome/browser/extensions/api/commands/command_service.cc b/chrome/browser/extensions/api/commands/command_service.cc
index 3656f4b98830ca5dbfcde76a2b77127600157e38..100b4fc67e83482537b59336b655e5c7b54041f6 100644
--- a/chrome/browser/extensions/api/commands/command_service.cc
+++ b/chrome/browser/extensions/api/commands/command_service.cc
@@ -19,6 +19,7 @@
 #include "chrome/browser/profiles/profile.h"
 #include "chrome/browser/ui/accelerator_utils.h"
 #include "chrome/common/extensions/api/commands/commands_handler.h"
+#include "chrome/common/extensions/extension_constants.h"
 #include "chrome/common/extensions/manifest_handlers/ui_overrides_handler.h"
 #include "chrome/common/pref_names.h"
 #include "components/pref_registry/pref_registry_syncable.h"
@@ -564,6 +565,10 @@ bool CommandService::CanAutoAssign(const Command &command,
         command.command_name() == manifest_values::kPageActionCommandEvent)
       return false;  // Browser and page actions are not global in nature.
 
+    if (extension->id() == extension_misc::kChromeVoxExtensionId) {
+      return true;
+    }

[Finnur, 2014/07/17 11:00:52]

This seems a bit hacky. We already have a permission system for extensions, with
the ability to restrict to certain platforms/extension IDs. That seems like a
better fit for this.

[David Tseng, 2014/07/18 22:54:50]

Are you referring to _permission_features(.json)?

If so, which permission did you have in mind?

[Finnur, 2014/08/11 14:01:07]

Yes, for example, you can check in code whether an extension has certain
permissions, such as fileSystem.write by doing:

extension->permissions_data()->HasAPIPermission(APIPermission::kFileSystemWrite);

For your purposes, you could add a section to _permission_features.json
called...

commands.accessibility
(or something)

... and whitelist your extension for that permission (and then check for that
permission here instead of the id). That way it is really easy to update the
list if we need to add other extensions to it. Furthermore, there might be more
places you need to add this check...

So, I can see three rule restrictions that, depending on the use case, one would
want relaxed:

1) Allow overwriting of already taken shortcuts.
2) Allow overwriting of *global* shortcuts other than Ctrl+Shift+[0-9].
Remember: Global shortcuts work when Chrome does not have focus.
3) Relax the restriction on the number of keys a developer can assign to one
extension (currently maxed out at 4, not counting MediaKeys).

So, your CL is relaxing only 2. Remind me again why it is important for
accessibility shortcuts to work when Chrome does _not_ have focus?

[David Tseng, 2014/08/19 22:47:49]

A few cases. Suppose focus (in Chrome OS) is on the views-based toolbar or if
there are no browser windows open at all. We still want an accessibility
extension to receive keyboard commands (e.g. to read the current time).

As for the points above, I think we will need all three relaxations.

[Finnur, 2014/08/20 12:41:14]

OK, then that's definitely something you'd want to add an API permission for,
because you'd otherwise have to spread if checks for the extension_id around the
codebase and we'd need to update each location when adding/removing extensions.
The HasAPIPermission makes us only have to update a single file to give/take
permission to/from an extension.

+
     // Global shortcuts are restricted to (Ctrl|Command)+Shift+[0-9].
 #if defined OS_MACOSX
     if (!command.accelerator().IsCmdDown())