If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[BT]The headset can't connect with headset automatically.

RESOLVED DUPLICATE of bug 891257

Status

Firefox OS
Gaia::Settings
P1
normal
RESOLVED DUPLICATE of bug 891257
4 years ago
4 years ago

People

(Reporter: sync-1, Unassigned)

Tracking

unspecified
1.1 QE4 (15jul)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:koi+, b2g18+ wontfix, b2g-v1.1hd wontfix, b2g-v1.2 affected)

Details

(Whiteboard: [TD-26809][TD-46493][mozilla-triage])

Attachments

(6 attachments, 4 obsolete attachments)

(Reporter)

Description

4 years ago
AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.107
 Firefox os  v1.0.1
 Mozilla build ID:20130514070202
 
 
 
 DEFECT DESCRIPTION:
 The headset can't connect with headset automatically.
 
 REPRODUCING PROCEDURES:
 1.Connect with a BT headset
 2.Turn off BT or reboot MS,cannot connect automatically and occur fail popup
 3.And then if you try to connect again, connection success.
 
 EXPECTED BEHAVIOUR:
 The headset can connect with headset automatically.
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:
 
 For FT PR, Please list reference mobile's behavior:
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Updated

4 years ago
blocking-b2g: --- → tef?
Component: Gaia::Bluetooth File Transfer → Gaia::Settings
Similar to bug 871957. Could you provide sniffer log or hcidump?

Comment 2

4 years ago
Created attachment 750378 [details]
The hci

Comment 3

4 years ago
(In reply to qingluo.wang from comment #2)
> Created attachment 750378 [details]
> The hcidump

Sorry,here is the description about this dump,as you see, it follows these steps:First connect with a headset, then restart the Bluetooth,you can find the error "connection rejected dues to limited resources".
I think this could become a blocker, but don't have strong feelings here. Alex, wdyt?
Flags: needinfo?(akeybl)
Whiteboard: [tef-triage]

Comment 5

4 years ago
I'm not sure this represents a user scenario warranting blocking status given where we are. What happens when the BT headset is turned off and on? If the user is disabling BT through the settings or airplane mode, it's likely that they turned off the headset in between as well.
Flags: needinfo?(akeybl) → needinfo?(sync-1)

Updated

4 years ago
Duplicate of this bug: 871957

Updated

4 years ago
Target Milestone: --- → 1.1 QE2

Comment 7

4 years ago
(In reply to Alex Keybl [:akeybl] from comment #5)
> I'm not sure this represents a user scenario warranting blocking status
> given where we are. What happens when the BT headset is turned off and on?
> If the user is disabling BT through the settings or airplane mode, it's
> likely that they turned off the headset in between as well.

Hi Alex,
Your explanation is available,but I think a better performance is the connection can be created automatically,and other OS like android can connect automatically,you can decide to ignore this issue now,but I still advise that to improve the auto-restore connection feature.
Flags: needinfo?(sync-1)
(In reply to qingluo.wang from comment #7)
> (In reply to Alex Keybl [:akeybl] from comment #5)
> > I'm not sure this represents a user scenario warranting blocking status
> > given where we are. What happens when the BT headset is turned off and on?
> > If the user is disabling BT through the settings or airplane mode, it's
> > likely that they turned off the headset in between as well.
> 
> Hi Alex,
> Your explanation is available,but I think a better performance is the
> connection can be created automatically,and other OS like android can
> connect automatically,you can decide to ignore this issue now,but I still
> advise that to improve the auto-restore connection feature.

Sure, we are tracking it to improve in future versions.
blocking-b2g: tef? → -
status-b2g18: --- → affected
tracking-b2g18: --- → +

Updated

4 years ago
Whiteboard: [tef-triage]

Comment 9

4 years ago
Dear Mozilla Team,

In my opinion, you need to fix this issue ASAP.

Because if this happened in the carkit, the user will need to click the phone while driving. So, it seems to be a very dangerous thing.

If you cannot change the scenario in which a connection request, I think that the connection is always guaranteed to be success.

Please check this point.
Thanks.

Updated

4 years ago
blocking-b2g: - → leo?
Whiteboard: [TD-26809]
Triage - Leo+ per comment 9 and agreed by triage discussion.
blocking-b2g: leo? → leo+
We do reconnect with the last connected headset automatically, or we wouln't receive the connection complete event with an error. Although this feature still has bug such as bug 862402, it should work most of the time under this scenario.

I think the problem is quite the same as bug 871962 - it's more related to the ability of chipset. From my point of view, there is not much we can do. I filed bug 873352 to stop discovering before trying to connect actively. That may help, but we still can't guarantee that Page Timeout won't occur anymore after the patch lands.

Another possible reason making this happen is that sometimes two devices would try to connect with each other at the same time, and hw or stack may or may not be capable of dealing with that.

Furthermore, this must not be 100% reproduciable. Could you please file bugs with the frequency next time? Thanks in advance.

Updated

4 years ago
See Also: → bug 862402

Updated

4 years ago
See Also: → bug 873352
Quick note: I have nominated bug 873352 as leo+.

Updated

4 years ago
Target Milestone: 1.1 QE2 (6jun) → 1.1 QE3 (24jun)
Blocks: 883821

Updated

4 years ago
Whiteboard: [TD-26809] → [TD-26809][TD-46493]
Hi Leo,

Since bug 862402 and bug 873352 have both landed on v1.1, please assist with checking if this bug still exists. Thank you.
Flags: needinfo?(leo.bugzilla.gecko)

Comment 14

4 years ago
Hi Eric,
bug 862402 and bug 873352 are applied. But still occurs.
Please confirm issue. Thank you.
Flags: needinfo?(leo.bugzilla.gecko)
Just tried the latest build (gecko:b2g18/gaia:v1-train) with Nokia BH-503 Bluetooth headset. If I turn off Bluetooth when the headset is connected and turn it on, Settings app would begin to try to restore the previous connection. However, from our UX design, discovery should be started when Bluetooth is enabled. That would increase the failure rate of connection, and that's why bug 873352 was filed.

Therefore I tried to add 'stopDiscovery()' function call right before 'setDeviceConnect(device)' in function restoreConnection() to see if it helps. Before revision, failure rate: 5/15; after revision, 1/10.

Leo, would you mind making the same revision and giving it a try? Feel free to tell me if you need any help. Thanks.
Flags: needinfo?(sync-1)
Flags: needinfo?(sync-1)
Flags: needinfo?(leo.bugzilla.gecko)

Updated

4 years ago
Assignee: nobody → echou

Comment 16

4 years ago
Hi, Eric

1. MW600 headset
leo devices all failed.(10/10)
The android device do not request for connecting with headset.(10/10)

2. HBS700 headset
leo devices success(1/10) and after you press the OK-Button on the pop-up window of failure-warning, connection will be successfully  completed 2~15 seconds later(9/10)
android devices all success.(10/10)

3. Jabra HAL02
leo devices all failed.(10/10)
The android device do not request for connecting with headset.(10/10)

Thanks.
Flags: needinfo?(leo.bugzilla.gecko)
(In reply to leo.bugzilla.gecko from comment #16)
> Hi, Eric
> 
> 1. MW600 headset
> leo devices all failed.(10/10)
> The android device do not request for connecting with headset.(10/10)
> 
> 2. HBS700 headset
> leo devices success(1/10) and after you press the OK-Button on the pop-up
> window of failure-warning, connection will be successfully  completed 2~15
> seconds later(9/10)
> android devices all success.(10/10)
> 
> 3. Jabra HAL02
> leo devices all failed.(10/10)
> The android device do not request for connecting with headset.(10/10)
> 
> Thanks.

Would you mind providing more details like video or hcidump? Especially for those 10/10 cases. The 100% failure rate sounds really unreasonable to me. Thanks.

Comment 18

4 years ago
Created attachment 765227 [details]
auto_connect_fail
(In reply to leo.bugzilla.gecko from comment #18)
> Created attachment 765227 [details]
> auto_connect_fail

Thanks.

Comment 20

4 years ago
Hi Eric,

I attached the video but cannot hcidump because bt off and on.
In my opinion, if there are previous connected devices, it seems that device search should not be action. Or auto connect looks like to need delay after bt on.
Please check your devices and this point.

Thanks.
(In reply to leo.bugzilla.gecko from comment #20)
> Hi Eric,
> 
> I attached the video but cannot hcidump because bt off and on.
> In my opinion, if there are previous connected devices, it seems that device
> search should not be action. Or auto connect looks like to need delay after
> bt on.
> Please check your devices and this point.
> 
> Thanks.

I'm ok with the change of delaying the timing of restoring connection if that could reduce failure rate. I'll make a patch.
Created attachment 765860 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/10530
Attachment #765860 - Flags: review?(arthur.chen)
Comment on attachment 765860 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/10530

Thank you for the effort! r=me.
Attachment #765860 - Flags: review?(arthur.chen) → review+
merged into gaia-master

https://github.com/mozilla-b2g/gaia/commit/24f577fb145acb74b0cbe28577f048799ab1e0c2
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Reopen because we need another patch to deal with the "Connection request would be rejected if the device has been connected" scenario.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Per comment 25, revert the patch.
master: https://github.com/mozilla-b2g/gaia/commit/59c7f4a59157a0bc1c45d705294395f988c509b2
deadline is Jun.27.
Assignee: echou → shuang
I have MW600 and applied the patch on Comment 23. It seems like we can still hit the problem "Page Timeout", and even though I added delay up to 8 seconds.
So I suspect it's something related to the fact that 

MW600 headset is trying to reconnect back, so at the same time the phone is trying to connect again, we got "Page timeout".

root@android:/ # hcidump                                                       
HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1504 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 5C:B5:24:62:D9:CD ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x04 handle 2 bdaddr 5C:B5:24:62:D9:CD type ACL encrypt 0x00
    Error: Page Timeout
I think i found the problem why even if applied the patch comment 23,
we still have chances got stuck, because that MW600 headset BT controller still remains
connected state after we turned off. The following log shows HCI command "Disconnect ACL" had been issued but before command actually been sent to phone BT controller, we send "HCI reset" before disconnection completed.
----------------------------------------------------------
---->When user turns off<----
< HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 2 reason 0x13
    Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
< HCI Command: Reset (0x03|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 4
    Reset (0x03|0x0003) ncmd 1
    status 0x00
device: disconnected
------------------------------>
next round
root@android:/ # hcidump                                                       
HCI sniffer - Bluetooth packet analyzer ver 2.0
Can't open device: No such device
root@android:/ # hcidump                                                       
HCI sniffer - Bluetooth packet analyzer ver 2.0
Can't open device: No such device
root@android:/ # hcidump                                                       
HCI sniffer - Bluetooth packet analyzer ver 2.0
Can't open device: No such device
root@android:/ # hcidump                                                       
HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1504 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 5C:B5:24:62:D9:CD ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x04 handle 2 bdaddr 5C:B5:24:62:D9:CD type ACL encrypt 0x00
    Error: Page Timeout
Created attachment 767111 [details] [diff] [review]
Improvement for ACL collision problem

This patch was generated by Eric pull request. I added 8 seconds delay because it's much safer time window with MW600. As test results show with leo device, we don't see restoring connection failure easily. This can improve a lot.
Can leo help to confirm this patch on different headsets?
Attachment #767111 - Flags: feedback?(leo.bugzilla.gecko)
Attachment #767111 - Attachment description: Improvement ACL collision problem → Improvement for ACL collision problem
Summary: [Buri][BT]The headset can't connect with headset automatically. → [BT]The headset can't connect with headset automatically.

Comment 31

4 years ago
Dear Shawn,

In my opinion, 8 seconds is very long time for reconnect.
User seem to attempt a connection before the 8 seconds.

I wonder it is needed to reconnect automatically.
Because headset request to phone and at the same time the phone is trying to connect again, Page Timeout fail.
And BT turn off and on very quickly, headset may not be ready to connect.

Eventually this reconnect scenario can cause the connection to fail a lot.
So I think reconnection is not required.

If you need reconnetion, I think it necessary to reduce the delay.
Thanks.
Reply Comment31:
I would agree automatically restoring connection is a trouble maker because connection collision can happen easily. Somehow, someone was complaining "reconnection feature" for v.1.0.1. So we added this feature on purpose.
8-second-delay could be a debate. Some bluetooth car kits would connect back or retry many times. So there is no general delay value to avoid collision. Some car kits would wait for a few seconds after powering on and connect back. The reason I picked 8 seconds just because let remote devices reconnect back would be a better idea. If the remote devices do not reconnect back in 8 seconds, we make a fallback to restore connection. However, this turns out be a heuristic method, there is a chance we could hit reconnection interval of remote devices.

If we want to make things better, we can check "class of device" with car audio mask, which uses a longer delay value. If "class of device" bits are not car audio mask (such as usual bluetooth headsets), we use shorter delay (2~3 seconds). OEM can fine tune the delay value since they have a better chance to test many bluetooth headsets. And yes, this is also a heuristic method, there is no guarantee that remote car kits use this mask.
Target Milestone: 1.1 QE3 (26jun) → ---
Target Milestone: --- → 1.1 QE3 (26jun)
bugzilla cannot update my comment32 because original target milestone is  1.1 QE3 (24jun). It somehow was modify to 1.1 QE3 (26Jun), so i need to change it again.
Attachment #767111 - Attachment is obsolete: true
Attachment #767111 - Flags: feedback?(leo.bugzilla.gecko)
Created attachment 767652 [details]
with extra check for COD value if it's car kit handsfree

I added extra check for car kits (if car kits has car audio mask). Can you try it?
Attachment #767652 - Flags: feedback?(leo.bugzilla.gecko)
I can only test on MW600, sorry.
Created attachment 767699 [details] [diff] [review]
Bug 872976- geco patch for hanlding ACL link fail to fully disconnect

Bug 872976- geco patch for hanlding ACL link fail to fully disconnect. I've tested with MW600 for 50 times (with turning on/off BT). I don't see any failure.
Attachment #767699 - Flags: feedback?(leo.bugzilla.gecko)
Unfortunately, I don't have Jabra HAL02 to verify. Please use both gecko/gaia patch to test with.
Thank you.

Comment 38

4 years ago
I tested several devices after apply patch.

* Test Result
1. Pass 
  - Headset: Sony MW600, Jabra HALO2, Samsung WEP 301/570
  - Carkit : Porsche PCM, Ford, Hyundai, KIA

2. Fail (Always)
  - Benz Carkit

3. Fail (sometimes)
  - LG HBS-700 , Motorola S9-HD (Fail rate: 50%)
  - And these devices almost failed when BT off/on in noti

I think that fail is occurred when headset send to phone connection request.
It is difficult to debug because timing issue depend on headset devices.
1. I appreciate all your efforts for testing so many models.
The design restoring connection of bluetooth setting is previously connected.
If b2g phone failed to benz car kit at the first time while restoring connection, at the time connection failure happens, next time user
turns on bluetooth, Setting would not restore connection again.
So collision shall only happen only once, and user shall still have chance to reconnect manually.

2.For Benz carkit (maybe 2010 model??), what the car kit behavior is actively restoring connection after ignition. If connection collision happen, it might be hard to connect with?
So I wonder checking COD of car audio is not enough. Would you mind provide my CoD value?
In apps/settings/js/bluetooth.js

           var deviceclass = device.class & 0x1FFC;
+          dump("device class: " + device.class);

In logcat, please provide this line.
I/GeckoDump( 1897): device class: 2360324
Can you also please provide failed devices Bluetooth friendly names.
Attachment #767652 - Attachment is obsolete: true
Attachment #767652 - Flags: feedback?(leo.bugzilla.gecko)
Created attachment 768195 [details] [diff] [review]
Gaia settings patch version 2
Attachment #768195 - Flags: feedback?(leo.bugzilla.gecko)

Comment 42

4 years ago
COD of Benz carkit is 3408904.
And Bluetooth friendly names used test are LG HBS700 and Motorola S9-HD
Attachment #768195 - Attachment is obsolete: true
Attachment #768195 - Flags: feedback?(leo.bugzilla.gecko)
Created attachment 768201 [details] [diff] [review]
Version 2- Avoid connection collision for specific devices

Add black list for specific devices which restore connection regressively and try to avoid potential connection collision.
Attachment #768201 - Flags: feedback?(leo.bugzilla.gecko)
Many bluetooth headsets do not reconnect actively, this is why we want to implement to restore connection. Some headsets/car kits recover connection aggressively and it could be easily hit collision while both sides are trying to connect with each other.
Eric, do you know which bug was fired for restoring connection feature?
It seems that iPhone does not do it but Android has this feature.
Flags: needinfo?(echou)
Oh, I found it's bug 826112 which request to restore connection. Clear ni?
Flags: needinfo?(echou)

Comment 46

4 years ago
I tested your patch and it is working well all.

But creating a blacklist of friendly names seems to have a problem.
If another device occur a collision, it is needed to add in blacklist and then it is not efficient design.

In my opinion I want to remove the restoring connection.
But if it is not possible, I suggest that you fix this bug until next QE not today. Because this collision seems to be fix after fully discussed with your bt team about restoring connection design.

How do you think about this?

* bug 826112 is applied in leo but this case is reproduced.
* Android phone does not seem to request to headset restoring connection.
Hi leo,
Original Android phone actually restore connection when BT was turned on/off. I tried Nexus 4, it works at that way. Can you confirm it again?
The patch is for your request due to QE3 deadline. Thanks for your understanding.

Comment 48

4 years ago
Hi Shawn,

I confirmed that Nexus 4 restore connection but LG and Samsung android phones do not restore connection.

I applied the patch of 5 second delay because it is mostly working headset without failure. Once I will proceed to next QE with this. 

Let's find the best way or design until next QE.
Thanks for your help.
Change milestone to QE4.
Target Milestone: 1.1 QE3 (26jun) → 1.1 QE4
Casey,
After patch of bug 872976 applied, we can observe some devices with connection collisions.
I think we shall discuss more about bug 826112. Collision problem is inevitable we introduced restore connection by default. Based on comment 48, LG/Samsung Android phones and iPhone, they all do not reconnect. If we introduce reconnection, we need to put some specific blacklist to skip reconnection or add delay time. But they are all devices specific tweak.
Flags: needinfo?(kyee)
(In reply to Shawn Huang from comment #50)
Fix typo.
Casey,
After patch of "bug 826112" applied, we can observe some devices with
connection collisions.
I think we shall discuss more about bug 826112. Collision problem is
inevitable we introduced restore connection by default. Based on comment 48,
LG/Samsung Android phones and iPhone, they all do not reconnect. If we
introduce reconnection, we need to put some specific blacklist to skip
reconnection or add delay time. But they are all devices specific tweak.
Duplicate of this bug: 884603
Summary:Based on Comment 48, patch works. But we need to have some more discussion here with BT team and UX team. I shall be able to update on July 2.
Attachment #767699 - Attachment is obsolete: true
Attachment #767699 - Flags: feedback?(leo.bugzilla.gecko)
Created attachment 768800 [details] [diff] [review]
b2g18 version
Created attachment 768802 [details] [diff] [review]
Wait for 100ms to make sure all acl links were dropped
Attachment #768802 - Flags: review?(gyeh)
Attachment #768802 - Flags: review?(echou)

Updated

4 years ago
Attachment #768201 - Flags: feedback?(leo.bugzilla.gecko)
This bug currently focus on "better" way to disconnect ACL links. Do we still need to discuss collision condition? Eric, do you have any comment?
Flags: needinfo?(echou)

Comment 57

4 years ago
I change leo? and I'll determine whether to apply in the future.
blocking-b2g: leo+ → leo?

Comment 58

4 years ago
I'm not clear on what a collision is and how it happens.  Can someone explain this to me in a user scenario?
Flags: needinfo?(kyee)
Collision: When the remote bluetooth device (such as Bluetooth Headset or car kit) connect to FXOS phone, at the same time, FXOS phone is trying to connect to the remote devices (while user just turned on bluetooth). What leo has concern the user scenario as the following:
(1) User turns on bluetooth headset
(2) The headset is trying to reconnect for a period of time
(3) User finds FXOS phone bluetooth function is not been enabled, so user tries to turn on bluetooth, then connection recovery
(4) While bluetooth headset is trying to reconnect and we can see collision.
Not sure what happened between comment 9 and comment 57 but it's up to Leo at this point whether to block on this and take the fix, we're close to the end of v1.1 cycles and Mozilla would not block on shipping for this issue.
Whiteboard: [TD-26809][TD-46493] → [TD-26809][TD-46493][mozilla-triage]

Comment 61

4 years ago
I nominate leo- because it is not block issue.
blocking-b2g: leo? → -
One of the reasons that auto restore connection fails easily is because we don't greacefully disconnect with the remote device, so that the remote device would try to reconnect with our device aggressively. 

I filed a new bug (bug 891257) to add the 'gracefully disconnect' mechanism. It's ready for review now, and I think that could largedy reduce the failure rate of auto restore connection.
Flags: needinfo?(echou)

Updated

4 years ago
Duplicate of this bug: 898702

Comment 64

4 years ago
Excuse me, I don't understand why it is not blocking anymore?

Or at least, can we set it as Koi?

Updated

4 years ago
blocking-b2g: - → koi?
Since bug 891257 was fixed, I think this issue may not be reproduciable (or at least not that easy to reproduce). However, I tried to nominate bug 891257 as a leo+ but failed, so the solution will not go into v1.1 (b2g18).
Comment on attachment 768802 [details] [diff] [review]
Wait for 100ms to make sure all acl links were dropped

Remove review request since we've got a better solution from bug 891257.
Attachment #768802 - Flags: review?(gyeh)
Attachment #768802 - Flags: review?(echou)
Ivan, +'ing due to partner request (comment 64)?

Shawn, would you continue working on that?

Ian, can you take over if Shawn couldn't work on this?
blocking-b2g: koi? → koi+
status-b2g18: affected → wontfix
status-b2g-v1.1hd: --- → wontfix
status-b2g-v1.2: --- → affected
Flags: needinfo?(shuang)
Flags: needinfo?(itsay)
Flags: needinfo?(iliu)
Tim, I just load the cause and effect of the issue from Arthur. I can help to follow up it.

Eric and Shawn, shall Gaia need to restore connection while Bluetooth is turning on? Looks like Settings ap has the mechanism in this case. The issue is happened when Settings app is closed. But we don't have the ability in System app. Could Bluetooth::Gecko have the ability to handle restore connection? Thanks.
Assignee: shuang → iliu
Flags: needinfo?(iliu)

Comment 69

4 years ago
Tim, agree this nomination.
Flags: needinfo?(itsay)
Tim and Ian, I would like to discuss this during BT backlog meeting on Tuesday (Oct 1). Moving auto-connect implementation to "Gecko" or "Gaia" seems not related to the original problem. Comment 65 mentioned had fixed the original problem. So I don't understand why this is still blocking.
Flags: needinfo?(shuang)
Per offline discussion w/ Eric, dup this bug with bug 891257 (see comment 65).

Ian, if comment 68 is a valid bug please file it.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 891257
Assignee: iliu → nobody
Let's track the issue of comment 68 and comment 70 on Bug 921927.
You need to log in before you can comment on or make changes to this bug.