There can only be one BluetoothAllowedDevicesMap per WebBluetoothService and we clean the map when navigating so the map will ever only deal with a single origin. We can get rid of some of the mapping and logic because of this.
As of today there are multiple BluetoothAllowedDevicesMap objects created for multiple frames:
. Renderer has a document with 3 same origin iframes:
. Each iframe calls navigator.bluetooth.requestDevice()
. Each iframe will construct a navigator.bluetooth blink::Bluetooth object
. Each blink::Bluetooth object will call
interfaceProvider->getInterface(mojo::MakeRequest(&m_service));
from within Bluetooth::requestDevice
. Each request will cause RenderFrameHostImpl::CreateWebBluetoothService
to be called, which will construct a new WebBluetoothServiceImpl object.
. Each service will create a BluetoothAllowedDevicesMap.
This isn't good, because multiple maps won't share knowledge of what is allowed between multiple frames.
It's debatable if there should be a 1:1 or a n:1 mapping of:
WebBluetoothServiceImpl :: origin in a profile.
In discussion, juncai and I are favoring n:1, as it is a bit more flexible in being able to have unique state per binding if ever necessary.
Both options need a new KeyedService & factory to provide common state that is tied to the single origin.
E.g. BluetoothAllowedDevicesMap will have a 1:1 mapping to to the origin in a profile. The keyed service can find or create one BluetoothAllowedDevicesMap object when the WebBluetoothServiceImpl instances are being created in RenderFrameHostImpl.
Then, the origin concept can be removed from BluetoothAllowedDevicesMap's implementation.
Comment 1 by scheib@chromium.org
, Jan 11 2017Status: Assigned (was: Available)