Add a kill switch for all of Web Bluetooth.

content/browser/bluetooth/bluetooth_dispatcher_host.cc

Index: content/browser/bluetooth/bluetooth_dispatcher_host.cc
diff --git a/content/browser/bluetooth/bluetooth_dispatcher_host.cc b/content/browser/bluetooth/bluetooth_dispatcher_host.cc
index b69fa4fa49f19a3632cda132998f947eec1a764d..9a189729b8941e50c3f094d8fe4a872b036fbd9b 100644
--- a/content/browser/bluetooth/bluetooth_dispatcher_host.cc
+++ b/content/browser/bluetooth/bluetooth_dispatcher_host.cc
@@ -1219,14 +1219,29 @@ void BluetoothDispatcherHost::OnRequestDeviceImpl(
     return;
   }
 
-  if (!GetContentClient()->browser()->AllowWebBluetooth(
-          web_contents->GetBrowserContext(), requesting_origin,
-          embedding_origin)) {
-    RecordRequestDeviceOutcome(
-        UMARequestDeviceOutcome::BLUETOOTH_CHOOSER_GLOBALLY_DISABLED);
-    Send(new BluetoothMsg_RequestDeviceError(
-        thread_id, request_id, WebBluetoothError::ChooserDisabled));
-    return;
+  switch (GetContentClient()->browser()->AllowWebBluetooth(

[ortuno, 2016/03/29 17:48:46]

Doing this so late in OnRequestDeviceImpl seems wrong. I think it would be
better if we did it before we try to initialize the adapter, in OnRequestDevice.

[Jeffrey Yasskin, 2016/03/29 23:13:04]

It probably makes sense to reconsider a lot of the requestDevice ordering, but
it's not intimately tied to adding the kill switch, so let's do it in a separate
patch? We're going to be forced to rearrange some of this anyway when we
refactor it into the PermissionContextBase structure, so let's think about it
then, unless there's some more urgent problem with this ordering.

+      web_contents->GetBrowserContext(), requesting_origin, embedding_origin)) {
+    case ContentBrowserClient::AllowWebBluetoothResult::BLOCK_POLICY: {
+      RecordRequestDeviceOutcome(
+          UMARequestDeviceOutcome::BLUETOOTH_CHOOSER_GLOBALLY_DISABLED);
+      Send(new BluetoothMsg_RequestDeviceError(
+          thread_id, request_id, WebBluetoothError::ChooserDisabled));
+      return;
+    }
+    case ContentBrowserClient::AllowWebBluetoothResult::BLOCK_KILL_SWITCH: {

[ortuno, 2016/03/29 17:48:46]

What do you think about checking if the WebBluetoothFlag is on? That way people
that know what they are doing can still use the feature?

[Jeffrey Yasskin, 2016/03/29 23:13:04]

For now, I think that prevents me from testing this change. I've filed
https://crbug.com/598890 to track this.

+      // Log to the developer console.
+      web_contents->GetMainFrame()->AddMessageToConsole(
+          content::CONSOLE_MESSAGE_LEVEL_LOG,
+          "Bluetooth permission has been blocked.");
+      // Block requests.
+      RecordRequestDeviceOutcome(
+          UMARequestDeviceOutcome::BLUETOOTH_KILL_SWITCH_ENABLED);
+      Send(new BluetoothMsg_RequestDeviceError(
+          thread_id, request_id, WebBluetoothError::KillSwitchEnabled));
+      return;
+    }
+    case ContentBrowserClient::AllowWebBluetoothResult::ALLOW:
+      break;
   }
 
   // Create storage for the information that backs the chooser, and show the