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

Status: RESOLVED DUPLICATE of bug 891257

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

Description

[sync-1]

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:

Comment 1

[Eric Chou [:ericchou] [:echou]]

Similar to bug 871957. Could you provide sniffer log or hcidump?

Comment 2

[qingluo.wang]

Attachment: The hci

Comment 3

[qingluo.wang]

(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".

Comment 4

[Daniel Coloma:dcoloma]

I think this could become a blocker, but don't have strong feelings here. Alex, wdyt?

Comment 5

[Alex Keybl [:akeybl]]

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.

Comment 7

[qingluo.wang]

(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.

Comment 8

[bhavana bajaj [:bajaj]]

(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.

Comment 9

[leo.bugzilla.gecko]

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.

Comment 10

[Wayne Chang [:wchang]]

Triage - Leo+ per comment 9 and agreed by triage discussion.

Comment 11

[Eric Chou [:ericchou] [:echou]]

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.

Comment 12

[Eric Chou [:ericchou] [:echou]]

Quick note: I have nominated bug 873352 as leo+.

Comment 13

[Eric Chou [:ericchou] [:echou]]

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.

Comment 14

[leo.bugzilla.gecko]

Hi Eric,
bug 862402 and bug 873352 are applied. But still occurs.
Please confirm issue. Thank you.

Comment 15

[Eric Chou [:ericchou] [:echou]]

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.

Comment 16

[leo.bugzilla.gecko]

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.

Comment 17

[Eric Chou [:ericchou] [:echou]]

(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

[leo.bugzilla.gecko]

Attachment: auto_connect_fail

Comment 19

[Eric Chou [:ericchou] [:echou]]

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

Thanks.

Comment 20

[leo.bugzilla.gecko]

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.

Comment 21

[Eric Chou [:ericchou] [:echou]]

(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.

Comment 22

[Eric Chou [:ericchou] [:echou]]

Attachment: Link to https://github.com/mozilla-b2g/gaia/pull/10530

Comment 23

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 765860 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/10530

Thank you for the effort! r=me.

Comment 24

[Eric Chou [:ericchou] [:echou]]

merged into gaia-master

https://github.com/mozilla-b2g/gaia/commit/24f577fb145acb74b0cbe28577f048799ab1e0c2

Comment 25

[Eric Chou [:ericchou] [:echou]]

Reopen because we need another patch to deal with the "Connection request would be rejected if the device has been connected" scenario.

Comment 26

[Arthur Chen [:arthurcc][inactive after 6/30]]

Per comment 25, revert the patch.
master: https://github.com/mozilla-b2g/gaia/commit/59c7f4a59157a0bc1c45d705294395f988c509b2

Comment 27

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

deadline is Jun.27.

Comment 28

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 29

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 30

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: 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?

Comment 31

[leo.bugzilla.gecko]

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.

Comment 32

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 33

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 34

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: 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?

Comment 35

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I can only test on MW600, sorry.

Comment 36

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: 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.

Comment 37

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Unfortunately, I don't have Jabra HAL02 to verify. Please use both gecko/gaia patch to test with.
Thank you.

Comment 38

[leo.bugzilla.gecko]

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.

Comment 39

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 40

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Can you also please provide failed devices Bluetooth friendly names.

Comment 41

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: Gaia settings patch version 2

Comment 42

[leo.bugzilla.gecko]

COD of Benz carkit is 3408904.
And Bluetooth friendly names used test are LG HBS700 and Motorola S9-HD

Comment 43

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: 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.

Comment 44

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 45

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Oh, I found it's bug 826112 which request to restore connection. Clear ni?

Comment 46

[leo.bugzilla.gecko]

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.

Comment 47

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

[leo.bugzilla.gecko]

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.

Comment 49

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Change milestone to QE4.

Comment 50

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 51

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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.

Comment 53

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 54

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: b2g18 version

Comment 55

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Attachment: Wait for 100ms to make sure all acl links were dropped

Comment 56

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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?

Comment 57

[leo.bugzilla.gecko]

I change leo? and I'll determine whether to apply in the future.

Comment 58

[Casey Yee]

I'm not clear on what a collision is and how it happens.  Can someone explain this to me in a user scenario?

Comment 59

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 60

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 61

[leo.bugzilla.gecko]

I nominate leo- because it is not block issue.

Comment 62

[Eric Chou [:ericchou] [:echou]]

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.

Comment 64

[Amelie Kong]

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

Or at least, can we set it as Koi?

Comment 65

[Eric Chou [:ericchou] [:echou]]

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 66

[Eric Chou [:ericchou] [:echou]]

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.

Comment 67

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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?

Comment 68

[[e-mail], [e-mail]]

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.

Comment 69

[Ivan Tsay (:ITsay)]

Tim, agree this nomination.

Comment 70

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 71

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 72

[[e-mail], [e-mail]]

Let's track the issue of comment 68 and comment 70 on Bug 921927.