New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 846900 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Web Bluetooth device chooser does not show adapter powered off message

Project Member Reported by reillyg@chromium.org, May 25 2018

Issue description

Chrome Version: 66.0.3359.181
OS: MacOS 10.13.3

What steps will reproduce the problem?
(1) Disable Bluetooth through the system menus
(2) Visit https://permission.site.
(3) Click the Bluetooth button.

What is the expected result?
Permissions dialog should display "Turn on Bluetooth to allow pairing" message.

What happens instead?
Permissions dialog is empty.

This issue appears to affect macOS but not Chrome OS. I have verified that Chrome is correctly identifying the adapter state. Something is preventing the UI from being displayed correctly.
 

Comment 1 by bsep@chromium.org, May 25 2018

Cc: ellyjo...@chromium.org
The interactive test seems to work on Windows, at least. I don't have a Mac to try it on. Cc'ing ellyjones@ for investigation.
Owner: jyasskin@chromium.org
Status: Assigned (was: Available)
I indeed do not see that message on Mac. Looking at the code, that can happen if BluetoothChooserController::OnAdapterPresenceChanged() is never called... perhaps the bluetooth code is broken on Mac?

Over to bluetooth owner :)
Owner: ellyjo...@chromium.org
That was my initial assumption but I put a breakpoint in the dialog code and verified that it is being told that the adapter is not present.
I can't think of any mac-specific reason why that should be the case. I'll take a look.
DeviceChooserContentView::OnAdapterEnabledChanged() is hiding table_view_ and showing adapter_off_help_, but I don't see table_view_ hide on Mac either. I think this is because the TableView is inside a ScrollView, and ScrollViews are layer-backed on Mac (because of layer scrolling) but not on other platforms. Layer children of a view V always draw above non-layer children of V, regardless of the child order of V.

If you hide table_parent_ instead of table_view_ in DeviceChooserContentView::OnAdapterEnabledChanged things should work on Mac, but I'm not sure if they look how you want.
Project Member

Comment 7 by bugdroid1@chromium.org, May 31 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/702071874d259e9a53acadf63bba6035ea091cd1

commit 702071874d259e9a53acadf63bba6035ea091cd1
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Thu May 31 17:48:18 2018

bluetooth: show bluetooth enable message

Hiding the tableview, while leaving its parent ScrollView visible, causes
problems on Mac where ScrollViews use layers internally.

Bug:  846900 
Change-Id: I94ca6d1f000f806d4218e4830fb68b790e45f798
Reviewed-on: https://chromium-review.googlesource.com/1080767
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563306}
[modify] https://crrev.com/702071874d259e9a53acadf63bba6035ea091cd1/chrome/browser/ui/views/device_chooser_content_view.cc
[modify] https://crrev.com/702071874d259e9a53acadf63bba6035ea091cd1/chrome/browser/ui/views/device_chooser_content_view_unittest.cc

Status: Fixed (was: Started)

Sign in to add a comment