bluetooth: Add FakeBluetooth interface

third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js

Index: third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js
diff --git a/third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js b/third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js
new file mode 100644
index 0000000000000000000000000000000000000000..3be6c6f1d19ec57c655db3b15ffd47b9c55677e6
--- /dev/null
+++ b/third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js
@@ -0,0 +1,47 @@
+(() => {
+  let mojo_;
+  let fake_bluetooth_;
+
+  async function getFakeBluetooth() {
+    if (typeof fake_bluetooth_ !== 'undefined') {
+      return fake_bluetooth_;
+    }
+
+    if (typeof loadMojoModules === 'undefined') {
+      throw 'Mojo is required for this API.'
+    }
+
+    mojo_ = await loadMojoModules('fakeBluetooth', [
+      'mojo/public/js/bindings',

[scheib, 2017/04/08 00:59:50]

Maybe OK, but we don't seem to use mojo_.bindings anywhere, so is it needed?

[ortuno, 2017/04/10 01:47:49]

I tried to remove it and mojo_.FakeBluetooth.FakeBluetooth became undefined. I
was thinking about adding a comment but then I figured that we shouldn't be
documenting Mojo in our code.

+      'device/bluetooth/public/interfaces/test/fake_bluetooth.mojom'
+    ]);
+
+    [mojo_.bindings, mojo_.FakeBluetooth] = mojo_.modules;
+
+    fake_bluetooth_ = new mojo_.FakeBluetooth.FakeBluetoothPtr(
+      mojo_.interfaces.getInterface(
+        mojo_.FakeBluetooth.FakeBluetooth.name));
+
+    return fake_bluetooth_;
+  }
+
+  class FakeBluetooth {

[scheib, 2017/04/08 00:59:50]

The FakeBluetooth class implements the specified fake bluetooth IDL in JS, using
the getFakeBluetooth above which gets the mojo interface connecting to our
implementation. The term FakeBluetooth is being used too much without describing
which layer it refers to.

One solution would be to not make a "class FakeBluetooth", since I don't believe
we ever need it to be a class nor to be named.

instead just:
navigator.bluetooth.test = {
  setLEAvailability: (available) => {
     ...
  }
}

[ortuno, 2017/04/10 01:47:49]

I feel as if I were implementing OO features using typedef, structs, and
function pointers in C++. I refactored the code a bit to make it more obvious
what each layer means. A small downside of using an object would be that our
polyfill becomes less accurate i.e. "console.log(navigator.bluetooth.test)"
would no longer print FakeBluetooth. Not that it matters that much given the
nature of the class' users.

+    constructor() {
+    }
+
+    async setLEAvailability(available) {
+      if (typeof available !== 'boolean') throw 'Type Not Supported';
+      await (await getFakeBluetooth()).setLEAvailability(available);
+
+      // TODO(crbug.com/569709): Remove once FakeBluetooth.setLEAvailability is
+      // implemented in the browser.
+      navigator.bluetooth.requestDevice = function() {
+        return Promise.reject(new DOMException(
+            'Bluetooth Low Energy is not supported on this platform.',
+            'NotFoundError'));
+        };
+    }
+  }
+
+  navigator.bluetooth.test = new FakeBluetooth();
+})();