Closed Bug 1069868 Opened 10 years ago Closed 10 years ago

Visibility setting is enabled after turn off bluetooth and turn on again

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, firefox34 wontfix, firefox35 wontfix, firefox36 fixed, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S7 (24Oct)
blocking-b2g 2.1+
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- fixed
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: shawnjohnjr, Assigned: jaliu)

Details

Attachments

(2 files, 2 obsolete files)

STR:
1. Turn on bluetooth
2. Disable 'Visible to all'
3. Turn off bluetooth and turn on again
Expected result:
'Visible to all' is disabled.

Actual result:
'Visible to all' enabled again.
This happened on flame-kk.
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Adding qawanted here for branch checks.
Keywords: qawanted
QA Contact: ckreinbring
The bug repros on KK Flame 2.2, Flame 2.1, Flame 2.0
Actual result: The Visible To All switch does not retain a non-default setting if Bluetooth is turned off and back on.  For 2.2 and 2.1, visibility is on by default.  For 2.0, visibility is off by default.

Flame 2.2
BuildID: 20140922040649
Gaia: 3802009e1ab6c3ddfc3eb15522e3140a96b33336
Gecko: 5e704397529b
Platform Version: 35.0a1
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1
BuildID: 20140922053548
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: 185fc54d29c1
Platform Version: 34.0a2
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0
BuildID: 20140922082143
Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba
Gecko: dc61f92b855e
Platform Version: 32.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: ckreinbring
not a regression, will backlog
blocking-b2g: 2.1? → backlog
Assignee: nobody → shuang
Same issue was reported by woodduck. set 2.0M? for triage.
blocking-b2g: backlog → 2.0M?
Sorry, wrong information. set it back to backlog.
blocking-b2g: 2.0M? → backlog
blocking-b2g: backlog → ---
(In reply to Evelyn Hung [:evelyn] from comment #7)
> Same issue was reported by woodduck. set 2.0M? for triage.

This is a different bug. Not the same problem happened on v2.0m.
Assignee: shuang → jaliu
It looks like Jamin already found the problem.
Attachment #8508512 - Flags: review?(shuang)
Comment on attachment 8508512 [details] [diff] [review]
(for 2.2) Set Bluetooth property |discoverable| to |false| after Bluetooth enabled. (v1)

Review of attachment 8508512 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for catching this. I indeed missed this part when doing review.
Attachment #8508512 - Flags: review?(shuang) → review+
[Blocking Requested - why for this release]:
This bug has been raised by CAF v2.1 BT issues from bug 1066235. This fixed by default Discoverable option is been enabled. Otherwise, it creates an unacceptable bluetooth visibility issue.
blocking-b2g: --- → 2.1?
Thank Shawn for reviewing the patch.
Attachment #8508512 - Attachment is obsolete: true
- fix a typo.
Attachment #8508524 - Attachment is obsolete: true
Try server:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=83406744fdaf
blocking-b2g: 2.1? → 2.1+
Comment on attachment 8508526 [details] [diff] [review]
(for 2.1) Set Bluetooth property |discoverable| to |false| after Bluetooth enabled. (v1), r=shuang

Approval Request Comment
[Feature/regressing bug #]:
This is a regressing bug which is caused by Bug 1038591.
The Bluetooth discoverable option in setting page is set to true by default.

[User impact if declined]:
1. Bluetooth discoverable is set to true by default, which is incorrect.
2. Even discoverable is set to true in setting page, the Bluetooth stack might still non-discoverable.

[Describe test coverage new/current, TBPL]:
I've tested it on flame-kk with Bluetooth API v2.

It looks fine on try server.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=83406744fdaf
P.S. I didn't trigger Mnw tests on try server since B2G emulator in TBPL uses BlueZ as Bluetooth stack and this bug is a BlueDroid bug.

[Risks and why]:
Bluetooth team is working on code refactoring and BLE API.
There will be many BT changes in 2.2.

[String/UUID change made/needed]:
None.
Attachment #8508526 - Flags: approval-mozilla-aurora?
Keywords: checkin-needed
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][COM=Bluetooth]
Comment on attachment 8508526 [details] [diff] [review]
(for 2.1) Set Bluetooth property |discoverable| to |false| after Bluetooth enabled. (v1), r=shuang

I should request approval for |b2g34| instead of |aurora|.
Sorry for inconvenience caused.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:

Comment on attachment 8508526 [details] [diff] [review] [diff] [review]
(for 2.1) Set Bluetooth property |discoverable| to |false| after Bluetooth enabled. (v1), r=shuang

Approval Request Comment
[Feature/regressing bug #]:
This is a regressing bug which is caused by Bug 1038591.
The Bluetooth discoverable option in setting page is set to true by default.

[User impact if declined]:
1. Bluetooth discoverable is set to true by default, which is incorrect.
2. Even discoverable is set to true in setting page, the Bluetooth stack might still non-discoverable.

[Describe test coverage new/current, TBPL]:
I've tested it on flame-kk with Bluetooth API v2.

It looks fine on try server.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=83406744fdaf
P.S. I didn't trigger Mnw tests on try server since B2G emulator in TBPL uses BlueZ as Bluetooth stack and this bug is a BlueDroid bug.

[Risks and why]:
Bluetooth team is working on code refactoring and BLE API.
There will be many BT changes in 2.2.

[String/UUID change made/needed]:
None.
Attachment #8508526 - Flags: approval-mozilla-aurora? → approval-mozilla-b2g34?
https://hg.mozilla.org/mozilla-central/rev/71fe1c412813
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S7 (24Oct)
This issue is verified fixed on Flame 2.2.
"Visible to all" is not enabled by enabling Bluetotth.

Flame 2.2 

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141023040204
Gaia: 27a1d1baaa8e375b70e043efee67d5f2206c330b
Gecko: 88adcf8fef83
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
==================================
Leaving verifyme keyword for Flame 2.1.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][COM=Bluetooth] → [QAnalyst-Triage?][COM=Bluetooth]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?][COM=Bluetooth] → [QAnalyst-Triage+][COM=Bluetooth]
Flags: needinfo?(ktucker)
Attachment #8508526 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
This issue is verified fixed on Flame 2.1.
"Visible to all" is not enabled by enabling Bluetooth.

Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141028001203
Gaia: a0174f7166745256aaca1cb3aa9f894033fbffa6
Gecko: 43bda3541f6b
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+][COM=Bluetooth] → [QAnalyst-Triage?][COM=Bluetooth]
QA Whiteboard: [QAnalyst-Triage?][COM=Bluetooth] → [QAnalyst-Triage+][COM=Bluetooth]
Flags: needinfo?(ktucker)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: