[Applet] Only re-enable BT after disabling airplane mode if it was on before
AbandonedPublic

Authored by ngraham on Tue, Nov 12, 9:22 PM.

Details

Reviewers
jgrulich
Group Reviewers
Plasma
Summary

Right now Bluetooth is unconditionally enabled after turning off airplane mode
regardless of whether or not it was on before. This patch fixes that.

BUG: 413967
FIXED-IN: 5.18.0

Test Plan
  1. Disable Bluetooth
  2. Enable airplane mode
  3. Disable airplane mode

Bluetooth stays off (the bug is fixed)

  1. Enable Bluetooth
  2. Enable airplane mode
  3. Disable airplane mode

Bluetooth stays on (no regression)

Diff Detail

Repository
R116 Plasma Network Management Applet
Branch
only-conditionally-re-enable-bluetooth-after-airplane-mode (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 18796
Build 18814: arc lint + arc unit
ngraham created this revision.Tue, Nov 12, 9:22 PM
Restricted Application added a project: Plasma. · View Herald TranscriptTue, Nov 12, 9:22 PM
Restricted Application added 1 blocking reviewer(s): jgrulich. · View Herald Transcript
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Tue, Nov 12, 9:22 PM

There is already a method to enable/disable BT, why don't you reuse it?

davidedmundson added inline comments.
libs/handler.cpp
366–369

You're asynchronously querying the bluetooth state with multiple calls.
Afterwards we send a call to disable bluetooth.

DBus will maintain order of individual calls, but N async things vs N async things is less determined

There is already a method to enable/disable BT, why don't you reuse it?

Nothing checks the previous BT status, so by the time we get to the function to enable BT, it can't know whether it was on before.

...Unless I'm misunderstanding you?

You are right, I didn't properly read what you do. I still think we should modify the already existing function to additionaly save the previous state, because most of the code is same. The only difference is "Set" vs "Get" method on DBus.

ngraham updated this revision to Diff 69753.Thu, Nov 14, 3:54 PM

--boilerplate

ngraham marked an inline comment as done.Thu, Nov 14, 8:15 PM

We were actually saving already the value of current BT state, it was just not used. Your code assumes there is just one BT adapter, while in theory there might be more of them. What I would just is just simply not add property like m_tmpBluetoothEnabled and use m_bluetoothAdapters to check if the specific BT adapter was enabled before, that's why we save the object path together with the value. This should be done in the else if (enable && m_bluetoothAdapters.value(objPath)) branch. Just check whether it was enabled before and enable it in that case.

Sorry for not looking into this properly before, I'm attending the LAS conference and didn't have that much time.

Hmm, reading the code more closely, it looks like it should already work. In fact, when I remove all my changes... it does work! I could have sworn that it didn't work before though.

Does this make any sense? Could it have been fixed by 7dd740aa963057c255fbbe83366504bbe48a240e?

Hmm, reading the code more closely, it looks like it should already work. In fact, when I remove all my changes... it does work! I could have sworn that it didn't work before though.

Does this make any sense? Could it have been fixed by 7dd740aa963057c255fbbe83366504bbe48a240e?

Not sure whether the change mentioned above, but it should indeed work just fine. The "else if" branch checks whether an adapter was enabled before so it does what it's supposed to do.

ngraham abandoned this revision.Mon, Nov 18, 4:18 PM