fido: fix a deadlock in waiting for BLE discovery to start
CL:1800725 changed FidoRequestHandlerBase's |notify_observer_callback_| barrier to block on each of the discoveries sending DiscoveryStarted() before reporting transport availability to the UI layer. However, on a machine with BLE available but powered off, FidoBleDiscoveryBase will never invoke DiscoveryStarted() until the adapter is powered on. Powering on the adapter is triggered by the UI after receiving the transport availability callback. Hence, with a powered-off BLE adapter, on requests instantiating the BLE discovery transport availability callback was never invoked, and as a result the UI never appeared. As it happens, the DiscoveryStarted() callback is rather redundant anyway. It's important for the platform discoveries (TouchID, Windows) as a way of ensuring their authenticators are added to the request handler, before signaling transport availability to the UI. But for Bluetooth specifically, there is a separate callback for determining Bluetooth availability and power status that the barrier waits on. Nothing the Bluetooth discovery does actually requires the UI to block. Therefore, this change modifies FidoBleDiscoveryBase to invoke DiscoveryStarted() right after enumerating Bluetooth adapters. As a side effect, the boolean |success| argument to DiscoveryStarted() now only signals whether the discovery found an adapter, whereas previously it also indicated e.g. whether caBLE advertising succeeded. But that doesn't really seem to matter since that argument is only ever consumed in unit tests anyway. Fixed: 1018416 Change-Id: I33549a24b1c399fee61374e44f5478f10d9db71d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1881974Reviewed-by:Adam Langley <agl@chromium.org> Reviewed-by:
Nina Satragno <nsatragno@chromium.org> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#711893}
Showing
Please register or sign in to comment