GitLab

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}