GNOME Bugzilla – Bug 764696
Bluetooth switch does not update when turning off from shell
Last modified: 2021-06-09 16:28:23 UTC
To reproduce: - make sure bluetooth is enabled - open bluetooth settings panel - from the shell, turn off bluetooth Expected results: - the settings panel updates the page to mention that bluetooth is now off - the switch on the bluetooth panel header turns off Actual results: - the settings panel correctly updates the page mentioning that bluetooth is now off - the switch on the bluetooth panel header *does not* turn off This seems to work fine in 3.18.2; the bug is introduced with this commit: https://git.gnome.org/browse/gnome-control-center/commit/panels/bluetooth/cc-bluetooth-panel.c?id=4a009da483e96ea1763855f419da64c9e2468a34 Since the shell only toggles off the BluetoothAirplaneMode property, that commit will make it so that the switch does not update.
Created attachment 325507 [details] [review] bluetooth: set switch off when BT airplane mode is enabled -- This seems to fix it for me, but I'm not sure if I'm missing something.
Pretty sure that's wrong, as it reverts my careful fix :) Which version of gnome-bluetooth are you using? What type of device are you testing this on? The output of "rfkill list" would help see whether I can reproduce this on a machine with a similar configuration. I tested this right now on a desktop with a single Bluetooth adapter right now, and it works fine: $ rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no
I can reproduce 100% of the time with the steps I described in comment #0 on Fedora 24 on my laptop. With bluetooth on: [cosimoc@yoga]$ rfkill list 0: ideapad_wlan: Wireless LAN Soft blocked: no Hard blocked: no 1: ideapad_bluetooth: Bluetooth Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 12: hci0: Bluetooth Soft blocked: no Hard blocked: no When I turn it off from the shell: [cosimoc@yoga]$ rfkill list 0: ideapad_wlan: Wireless LAN Soft blocked: no Hard blocked: no 1: ideapad_bluetooth: Bluetooth Soft blocked: yes Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 12: hci0: Bluetooth Soft blocked: yes Hard blocked: no
Oh, also the patch does not revert completely your fix - I left in place the connection to the "adapter-status-changed" signal.
Bastien, did you have any chance to take look at this?
Bastien, any news on this one?
I can reproduce this on a ThinkPad x220 and a 2nd generation X1.
*** Bug 775711 has been marked as a duplicate of this bug. ***
I have the same bug on my macbook.
Created attachment 351664 [details] [review] bluetooth: Show a wait screen while bluetooth is being turned on When rfkill is turned off it may take some time for the bluetooth device to be ready (in particular if there is hardware power control as the USB device needs to be registered first). During this time, show a special page asking for the user to wait.
So, I think the logic for this check has been wrong much longer. The check did: bt_airplane_mode || !powered -> Default adapter is unpowered, but should be available But it should be: !bt_airplane_mode && !powered i.e. airplane mode is turned OFF, and the bluetooth dongle is not yet powered up.
I realised that we could deal with users getting stuck in a broken rfkill state by showing the button as "Off". That is not a great UI as the button will jump back to the "Off" state immediately after turning bluetooth on. However, it enables to escape a broken rfkill state (see bug #782532 for more details). Thoughts?
Review of attachment 351664 [details] [review]: No, a separate page is unnecessary and unwanted.
In old GNOME HIG times I remember a note that you should give feedback for anything taking longer than 100ms. And it can take in the range of seconds after you toggle the switch in the control center for bluetooth to become available. I absolutely agree that not changing the UI in the stable branches is the right thing to do and was already planning to submit a separate patch for that purpose.
(In reply to Benjamin Berg from comment #14) > In old GNOME HIG times I remember a note that you should give feedback for > anything taking longer than 100ms. And it can take in the range of seconds > after you toggle the switch in the control center for bluetooth to become > available. I'd rather have a spinner next to the switch, while the operation is ongoing. A separate page would be really jarring if the changes happen within a second...
Created attachment 351970 [details] [review] bluetooth: Show disabled screen with switch ON while transitioning When rfkill is turned off it may take some time for the bluetooth device to be ready (in particular if there is hardware power control as the USB device needs to be registered first). During this time show the switch to be ON but still show the disabled page as not enough information is available yet (in particular the bluetooth name). -- This is a version without the UI change. Note that I forgot to remove the change_powered boolean earlier and that is fixed in this revision.
Created attachment 351971 [details] [review] bluetooth: Show disabled screen with switch ON while transitioning When rfkill is turned off it may take some time for the bluetooth device to be ready (in particular if there is hardware power control as the USB device needs to be registered first). During this time show the switch to be ON but still show the disabled page as not enough information is available yet (in particular the bluetooth name).
Sorry, I had been experimenting with the UI a bit after submitting the patch so the last version accidentally set the switch state to FALSE instead of TRUE. Now the logic should be sane.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.