Adding Chrome-side WebVR interface

content/browser/vr/vr_device.cc

Index: content/browser/vr/vr_device.cc
diff --git a/content/browser/vr/vr_device.cc b/content/browser/vr/vr_device.cc
new file mode 100644
index 0000000000000000000000000000000000000000..abbf2474e5d0980f034afec88479defe44cce557
--- /dev/null
+++ b/content/browser/vr/vr_device.cc
@@ -0,0 +1,21 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "content/browser/vr/vr_device.h"
+#include "content/browser/vr/vr_device_provider.h"
+
+namespace content {
+
+unsigned int VRDevice::next_id_ = 1;
+
+VRDevice::VRDevice(VRDeviceProvider* provider)
+    : provider_(provider)
+    , id_(next_id_) {
+  next_id_++;

[mdempsky, 2015/05/11 19:25:01]

Are VRDevices guaranteed to be created in a single thread?

What happens if next_id_ wraps around?  Is it possible for an attacker on the
web to create and destroy 2^32 VRDevice objects so that IDs are reused?

[bajones, 2015/05/12 00:13:39]

Theoretically, I suppose if you opened a tab, queried VR devices, closed the
tab, and then repeated that a couple billion times, sure. I think at that point
I'm happy to stop returning VR devices, though. I'll add some simple logic to
handle/prevent the wraparound case.

+}
+
+VRDevice::~VRDevice() {
+}
+
+}  // namespace content