Showing devices transport method in one device

chrome/common/extensions/permissions/chrome_permission_message_provider.cc

Index: chrome/common/extensions/permissions/chrome_permission_message_provider.cc
diff --git a/chrome/common/extensions/permissions/chrome_permission_message_provider.cc b/chrome/common/extensions/permissions/chrome_permission_message_provider.cc
index 6fa8e5b9c0e14fbaf31c5074cdf31ba242b6a184..7f5f19d116f99d081f6f8498623616a19f121baa 100644
--- a/chrome/common/extensions/permissions/chrome_permission_message_provider.cc
+++ b/chrome/common/extensions/permissions/chrome_permission_message_provider.cc
@@ -111,6 +111,8 @@ std::vector<base::string16> ChromePermissionMessageProvider::GetWarningMessages(
   bool media_galleries_read = false;
   bool media_galleries_copy_to = false;
   bool media_galleries_delete = false;
+  int access_to_devices = 0;
+  bool access_to_devices_message_pushed = false;
   for (PermissionMessages::const_iterator i = messages.begin();
        i != messages.end(); ++i) {
     switch (i->id()) {
@@ -129,6 +131,11 @@ std::vector<base::string16> ChromePermissionMessageProvider::GetWarningMessages(
       case PermissionMessage::kMediaGalleriesAllGalleriesDelete:
         media_galleries_delete = true;
         break;
+      case PermissionMessage::kBluetoothDevices:
+      case PermissionMessage::kHid:
+      case PermissionMessage::kSerial:
+      case PermissionMessage::kUsbDevice:

[meacer, 2014/06/18 02:25:02]

These should be kUsb and kBluetooth instead, as those are the permissions
allowing device enumeration. As a quick test, you can create a simple manifest
and check the permissions in chrome://extensions page:

{ "name": "Test,"
  "manifest_version": 2,
  "version": "1.0",
  "permissions": ["usb", "bluetooth"]
}

[Ken Rockot(use gerrit already), 2014/06/18 21:06:17]

kUsb and kBluetooth are correct, yes.

The k[Usb,Bluetooth]Device(s) permissions are for listing more specific device
constraints (like VID/PID for a USB device). They're a practical prerequisite
for using the APIs, but they are not interesting permissions in this case, I
think.

[mhm, 2014/06/18 22:16:44]

rockot@ aren't these two only used to list the Bluetooth/USb device and not to
access the devices themselves?

+        access_to_devices += 1;
       default:
         break;
     }
@@ -137,6 +144,19 @@ std::vector<base::string16> ChromePermissionMessageProvider::GetWarningMessages(
   for (PermissionMessages::const_iterator i = messages.begin();
        i != messages.end(); ++i) {
     int id = i->id();
+    if (access_to_devices > 1) {
+      if (!access_to_devices_message_pushed) {
+        message_strings.push_back(
+            l10n_util::GetStringUTF16(IDS_EXTENSION_PROMPT_WARNING_DEVICES));
+        access_to_devices_message_pushed = true;
+        continue;
+      }
+      if (id == PermissionMessage::kBluetoothDevices ||
+          id == PermissionMessage::kHid || id == PermissionMessage::kSerial ||
+          id == PermissionMessage::kUsbDevice) {
+        continue;
+      }

[not at google - send to devlin, 2014/06/18 20:53:32]

I think the upgrade path here is a bit weird. What if I install an extensoin and
it says "access to your bluetooth devices" and then it upgrades and says "access
to your hardware".

I'm ok with just grouping these no matter what ("access to hardware"). Perhaps
ideally we'd turn usb + bluetooth into "your usb and bluetooth devices" but that
would require setting up a full ManifestPermission for this:
https://code.google.com/p/chromium/codesearch#chromium/src/extensions/common/...

+    }
     if (audio_capture && video_capture) {
       if (id == PermissionMessage::kAudioCapture) {
         message_strings.push_back(l10n_util::GetStringUTF16(