bluetooth: Handle two consecutives requestDevice calls.

content/browser/bluetooth/web_bluetooth_service_impl.cc

 // Copyright 2016 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.
 
 // ID Not In Map Note:
 // A service, characteristic, or descriptor ID not in the corresponding
 // WebBluetoothServiceImpl map [service_id_to_device_address_,
 // characteristic_id_to_service_id_, descriptor_to_characteristic_] implies a
 // hostile renderer because a renderer obtains the corresponding ID from this
 // class and it will be added to the map at that time.
@@ skipping 632 matching lines @@
   }
   notify_session_iter->second->Stop(base::Bind(
       &WebBluetoothServiceImpl::OnStopNotifySessionComplete,
       weak_ptr_factory_.GetWeakPtr(), characteristic_instance_id, callback));
 }
 
 void WebBluetoothServiceImpl::RequestDeviceImpl(
     blink::mojom::WebBluetoothRequestDeviceOptionsPtr options,
     const RequestDeviceCallback& callback,
     device::BluetoothAdapter* adapter) {
-  // requestDevice() can only be called when processing a user-gesture and
-  // any user gesture outside of a chooser should close the chooser so we should
-  // never get a request with an open chooser.
-  CHECK(!device_chooser_controller_.get());
+  // requestDevice() can only be called when processing a user-gesture and any
+  // user gesture outside of a chooser should close the chooser. But this does
+  // not happen on all platforms so we manually close any open choosers.
+  device_chooser_controller_.reset();

[Jeffrey Yasskin, 2016/06/10 00:49:22]

Can you just delete this line? That'll wind up destroying the old controller
after the new one is created, but I don't think that has an effect. If it is
important to keep the destroy, create order, comment why.

[ortuno, 2016/06/10 18:10:07]

I revised the comment. Let me know if you don't think that's enough.

[Jeffrey Yasskin, 2016/06/10 18:47:18]

Well, the second chooser doesn't open until you call ->GetDevice(), which
definitely happens after the old one is destroyed. It's only the construction of
the object that would happen earlier, and that doesn't look like it has any
side-effects.

We could say something like "so we don't DCHECK that the old one is closed. We
destroy the old chooser before constructing the new one to make sure they can't
conflict."

[ortuno, 2016/06/10 19:32:01]

Done. Thanks for the suggestion!

 
   device_chooser_controller_.reset(new BluetoothDeviceChooserController(
       this, render_frame_host_, adapter,
       GetBluetoothAdapterFactoryWrapper()->GetScanDuration()));
 
   device_chooser_controller_->GetDevice(
       std::move(options),
       base::Bind(&WebBluetoothServiceImpl::OnGetDeviceSuccess,
                  weak_ptr_factory_.GetWeakPtr(), callback),
       base::Bind(&WebBluetoothServiceImpl::OnGetDeviceFailed,
@@ skipping 286 matching lines @@
   characteristic_id_to_service_id_.clear();
   service_id_to_device_address_.clear();
   connected_devices_.reset(
       new FrameConnectedBluetoothDevices(render_frame_host_));
   allowed_devices_map_ = BluetoothAllowedDevicesMap();
   device_chooser_controller_.reset();
   GetBluetoothAdapterFactoryWrapper()->ReleaseAdapter(this);
 }
 
 }  // namespace content