bluetooth: Use WebBluetoothDeviceId instead of string

third_party/WebKit/public/blink.gyp

Index: third_party/WebKit/public/blink.gyp
diff --git a/third_party/WebKit/public/blink.gyp b/third_party/WebKit/public/blink.gyp
index 7a44309465f4980c1a0c5b9d5beb2e344f9e7d30..743334987966ed5048119885449340f2cd11771f 100644
--- a/third_party/WebKit/public/blink.gyp
+++ b/third_party/WebKit/public/blink.gyp
@@ -36,7 +36,6 @@
         'blink_mojo_sources': [
             'platform/mime_registry.mojom',
             'platform/modules/background_sync/background_sync.mojom',
-            'platform/modules/bluetooth/web_bluetooth.mojom',
             'platform/modules/geolocation/geolocation.mojom',
             'platform/modules/notifications/notification.mojom',
             'platform/modules/notifications/notification_service.mojom',
@@ -114,6 +113,7 @@
                 'mojom_files': [
                     '<@(blink_mojo_sources)',
                     '<@(blink_android_mojo_sources)',
+                    'platform/modules/bluetooth/web_bluetooth.mojom',

[jbroman, 2016/07/14 15:14:24]

Why is this being taken out of the Chromium variant? I'd expect both targets to
include the same .mojom files.

[ortuno, 2016/07/15 00:05:12]

blink.gyp generates both chromium and blink variant bindings e.g.
web_bluetooth.mojom.h and web_bluetooth.mojom-blink.h. I think this is wrong,
blink.gyp should only generate blink bindings and chromium should generate its
own bindings. This becomes apparent in this case because the chromium bindings
now depend on content/common. This would mean that we would need to add a
dependency on content/common in this file, which I believe we don't want. To
avoid that, this patch moves the Web Bluetooth chromium binding generation to
content/content_common_mojo_bindings.gyp. I'm happy to move the whole non-blink
variant to content if we think that's the right solution.

[jbroman, 2016/07/15 17:10:33]

Have you brought this up on chromium-mojo@? I'd rather not see us get into an
inconsistent state here. I can see arguments in both directions, but I really
think this needs to be predictable so that Chromium developers can easily locate
the correct target to use mojo bindings.

[ortuno, 2016/07/15 18:23:16]

I did not, mainly because whatever we decide to do is very temporary. Last time
I checked there were no gyp bots in the cq, and I've heard that we are not going
to have to worry about gyp in the next week or two.

                 ],
                 'mojom_typemaps': [
                     '<(DEPTH)/cc/ipc/surface_id.typemap',
@@ -139,7 +139,6 @@
                     '<@(blink_android_mojo_sources)',
                 ],
                 'mojom_typemaps': [
-                  '../../../device/bluetooth/public/interfaces/bluetooth_uuid.typemap',
                     '<(DEPTH)/cc/ipc/surface_id.typemap',
                     '<(DEPTH)/cc/ipc/surface_sequence.typemap',
                 ],
@@ -161,7 +160,6 @@
                 'mojo_bindings_blink_mojom',
                 'mojo_bindings_mojom',
                 '../../../mojo/mojo_public.gyp:mojo_cpp_bindings',
-                '../../../device/bluetooth/bluetooth.gyp:bluetooth_mojom',

[jbroman, 2016/07/14 15:14:24]

Why are these no longer needed? device.mojom.BluetoothUUID still seems to be in
use.

[ortuno, 2016/07/15 00:05:12]

Ah right. I accidentally moved this to content.

                 '<(DEPTH)/cc/ipc/cc_ipc.gyp:interfaces',
                 '<(DEPTH)/cc/ipc/cc_ipc.gyp:interfaces_blink',
             ],