mac: Bluetooth adapter is called on chrome start up |
||||||||
Issue descriptionChrome Version : 58.0.3013.0 OS version : Mac OS X What steps will reproduce the problem? (1) Open Chrome What is the expected result? Chrome is opened. Bluetooth adapter should not be queried as it doesn't need this information on start up. What happens instead? Chrome asks for Bluetooth adapter address. See logs: Feb 15 16:49:08.336 NOTE 00:00:00:00:00:00 0x0000 OS X Version 10.12.3 (Build 16D32) / Model ID: MacBookAir7,2 Feb 15 16:49:08.338 NOTE 00:00:00:00:00:00 0x0000 Bluetooth Software Version: 5.0.3f1 Feb 15 16:49:08.338 NOTE 00:00:00:00:00:00 0x0000 Host Controller: Broadcom / 0x05AC / 0x828F / v131 c9231 / Built-In (Yes) / Location ID (0x14330000) Feb 15 16:49:08.338 NOTE 00:00:00:00:00:00 0x0000 Support: Deep Idle (Yes) / WoBT (Yes) / BTRS (No) / New Idle Policy (Yes) / Idle Time (500 ms) Feb 15 16:49:14.273 HCI COMMAND 00:00:00:00:00:00 0x0000 [1009] Read Device Address Feb 15 16:49:14.273 KERNEL DEBUG 00:00:00:00:00:00 0x0000 [0x2000] [IOBluetoothHCIRequest][Start] -- OpCode 0x1009 (Read Device Address) from: Google Chrome Ca (79130) Synchronous status: 0x00 (kIOReturnSuccess) state: 2 (BUSY) timeout: 4321 Feb 15 16:49:14.274 HCI EVENT 98:E0:D9:A5:0D:B4 0x0000 [1009] Command Complete - Read Device Address
,
Feb 15 2017
It's not Web Bluetooth. The adapter is being initialized through: EasyUnlockService::InitializeOnAppManagerReady() I thought Easy Unlock in chrome was only supported on ChromeOS.
,
Feb 15 2017
+tengs who's more familiar with Easy unlock
,
Feb 16 2017
,
Feb 16 2017
I think I found the culprit 2 years old CL at https://codereview.chromium.org/1023823002. Statistics about what Bluetooth capabilities are available will determine how the EasyUnlock feature gets developed and deployed across platforms. This value is logged only once during the lifetime of the Chrome process, shortly after it starts up. If a Bluetooth USB adapter is inserted after that point, the change will not be registered until Chrome restarts. I would be in favor of reverting it. WDYT?
,
Feb 16 2017
Are we actually looking at this metric? If not, I would be in favor of reverting it.
,
Feb 16 2017
I'm not looking at it and no longer work on BT related things. Feel free to remove it if nobody else is.
,
Feb 17 2017
I've uploaded a CL at https://codereview.chromium.org/2702683003/ that removes Bluetooth adapter status UMA.
,
Feb 19 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b218ccd8ae08ba89f2038c10a2aa746dff8a424d commit b218ccd8ae08ba89f2038c10a2aa746dff8a424d Author: beaufort.francois <beaufort.francois@gmail.com> Date: Sun Feb 19 07:55:58 2017 Remove Bluetooth adapter status UMA. BUG= 692570 Review-Url: https://codereview.chromium.org/2702683003 Cr-Commit-Position: refs/heads/master@{#451518} [modify] https://crrev.com/b218ccd8ae08ba89f2038c10a2aa746dff8a424d/chrome/browser/signin/easy_unlock_service.cc [modify] https://crrev.com/b218ccd8ae08ba89f2038c10a2aa746dff8a424d/tools/metrics/histograms/histograms.xml
,
Feb 20 2017
Verified in Chrome Canary 58.0.3018.0. Yeah! |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rsesek@chromium.org
, Feb 15 2017Components: -IO>Bluetooth Blink>Bluetooth
Labels: -Pri-3 Pri-1