989742 - [Tarako][Settings][Bluetooth] Unable to pair devices when a foreground app(not Settings app) is running.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Bluetooth, defect)

Description

[Bingqing Li]

Environment:
-----------------------
Gaia 14ef4fcdf9199f04f7678755c917dc77f51e13ba
Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/b574a7967338
BuildID 20140329004002
Version 28.1
ro.build.version.incremental=70
ro.build.date=Fri Mar 28 06:17:40 CST 2014


Steps to reproduce:
-----------------------
1. Disable bluetooth
2. Send a file via bluetooth
   e.g. Goto Music, and share a music via bluetooth
3. Confirm to enable bluetooth
4. Tap on a device which is in the “devices in the area” list


Actual results:
----------------------
Unable to pair the device, and there is a error message saying "Unable to pair with the device.Check that the PIN is correct."

Comment 1

[Keven Kuo [:kkuo]]

Hi! Eric,

Could BT team help on this case?
Thanks

--
Keven

Comment 2

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

Sure. I'll investigate first.

Comment 3

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

I tried to reproduce with Tarako and hit into several different situations:

(1) Pairing dialog was shown and file-sharing process succeeded
(2) Pairing error dialog was shown.
(3) Pairing dialog was shown. After tapping 'pair', the pairing process started, however file-sharing failed.

I'll dig into more details tomorrow.

Comment 4

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

In my test experience, sharing media to GT-I9100, GT-I9100 does not show any pairing message. And Tarako show "Unable to pair the device" dialog as description actual result. I suspect that Tarako might not send out pairing request in this case.

Eric, any help in Gaia side, please feel free to let me know. Thanks.

Gaia      cc0f31ec4509d5067bf155fd7ea38425dcbe39eb
Gecko     57625761da9e5c35d1ddd516221ce274a3575d15
BuildID   20140325060053
Version   28.0
ro.build.version.incremental=121
ro.build.date=Tue Mar 25 06:09:04 CST 2014

Comment 5

[bhavana bajaj [:bajaj]]

(In reply to Bingqing Li from comment #0)
> Environment:
> -----------------------
> Gaia 14ef4fcdf9199f04f7678755c917dc77f51e13ba
> Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/b574a7967338
> BuildID 20140329004002
> Version 28.1
> ro.build.version.incremental=70
> ro.build.date=Fri Mar 28 06:17:40 CST 2014
> 
> 
> Steps to reproduce:
> -----------------------
> 1. Disable bluetooth
> 2. Send a file via bluetooth
>    e.g. Goto Music, and share a music via bluetooth
> 3. Confirm to enable bluetooth
> 4. Tap on a device which is in the “devices in the area” list
> 
> 
> Actual results:
> ----------------------
> Unable to pair the device, and there is a error message saying "Unable to
> pair with the device.Check that the PIN is correct."

Can you confirm this case works well on 1.3 and 1.4 ?

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

1.3 buri : expected result occurs when paired with 1.3 open C so long as the bluetooth turns on for the buri before the time out on the Open C
1.4 buri : expected result occurs when paired with 1.3 open C so long as the bluetooth turns on for the buri before the time out on the Open C

Gaia      216cc2e5c8692ba71aa78a9f27e84e9da27952b8
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/9223243c65a2
BuildID   20140401000202
Version   30.0a2
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013
Buri

Gaia      24f562fce468fc948ac9e6185e002c23350cb9ee
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/0adf24a785f2
BuildID   20140401004003
Version   28.0
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013
Buri

Comment 7

[Ben Tian (inactive)]

[STR] I can reproduce this bug by simply pair in settings app.

Bingqing/Xinhe, please check your bluetooth stack because this bug cause seems the same as bug 938002 comment 31. Hcidump logs show remote device fails to authenticate after receiving user confirmation reply, while gecko only sets 'confirm=true' to bluez stack.

Hcidump logs:
< HCI Command: User Confirmation Request Reply (0x01|0x002c) plen 6
    bdaddr F0:E7:7E:E1:51:62
> HCI Event: Command Complete (0x0e) plen 10
    User Confirmation Request Reply (0x01|0x002c) ncmd 1
    status 0x00 bdaddr F0:E7:7E:E1:51:62
> HCI Event: Simple Pairing Complete (0x36) plen 7
    status 0x05 bdaddr F0:E7:7E:E1:51:62
    Error: Authentication Failure
> HCI Event: Auth Complete (0x06) plen 3
    status 0x05 handle 50
    Error: Authentication Failure
< HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 50 reason 0x13
    Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 50 mode 0x00 interval 0
    Mode: Active
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 50 reason 0x16
    Reason: Connection Terminated by Local Host

Comment 8

[James Zhang (Spreadtrum)]

It's not bluetooth issue, it's LMK issue.
Setting apps is killed by LMK.

Comment 9

[James Zhang (Spreadtrum)]

I think bluetooth can use its own activity, don't depend on setting apps. Setting apps is too large and use too much memory, it's often killed by LMK when video/music playback and can't receive bluetooth message.



294925/slog_20140328182455_sp6821a_userdebug/external_storage/last_log/20140328165020/kernel/kernel.log:03-28 17:03:00.935 <4>0[  764.585631] select 1268 (Settings), adj 10, size 6617, to kill
294925/slog_20140328182455_sp6821a_userdebug/external_storage/last_log/20140328165020/kernel/kernel.log:03-28 17:03:00.935 <4>0[  764.585697] send sigkill to 1268 (Settings), adj 10, size 6617
294925/slog_20140328182455_sp6821a_userdebug/external_storage/last_log/20140328165020/kernel/kernel.log:03-28 17:05:30.666 <4>0[  914.313434] select 1658 (Settings), adj 10, size 6756, to kill
294925/slog_20140328182455_sp6821a_userdebug/external_storage/last_log/20140328165020/kernel/kernel.log:03-28 17:05:30.666 <4>0[  914.313504] send sigkill to 1658 (Settings), adj 10, size 6756
294925/slog_20140328182455_sp6821a_userdebug/external_storage/last_log/20140328165020/android/main.log:03-28 17:06:53.422  1900  1900 I log     : <4>0[ 997.063104] select 1794 (Settings), adj 10, size 7040, to kill

Comment 10

[Bingqing Li]

Attachment: hcidump log

Comment 11

[Bingqing Li]

Attachment: logcat

Comment 12

[Ben Tian (inactive)]

(In reply to James Zhang from comment #8)
> It's not bluetooth issue, it's LMK issue.
> Setting apps is killed by LMK.
The diagnosis is weird since in original STR Settings app is still able to show error message.

comment 0:
Actual results:
----------------------
Unable to pair the device, and there is a error message saying "Unable to pair with the device.Check that the PIN is correct."

Comment 13

[Joe Cheng [:jcheng] (please needinfo)]

hi James, can you please have your team to look at https://bugzilla.mozilla.org/show_bug.cgi?id=989742#c7? base on the STR and our investigation, we do not believe settings app is killed. thanks

Comment 14

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

There are two symptoms in this bug:

(1) the pairing error dialog appears.
(2) "bluetooth file transfer" app gets killed.

Apparently the description mentioned in comment 0 is (1), and I can hardly reproduce (2). Therefore I'll talk more about (1).

Just tested by using my Tarako with the latest Gecko/Gaia. Log is attached below: 

I/GeckoBluetooth(   84): Notify: [S] Notify: RequestConfirmation
I/Gecko   (   84): -- SystemMessageInternal 1410374383630 : Broadcasting bluetooth-pairing-request {"address":"28:9A:FA:B5:21:50","method":"confirmation","passkey":871933,"name":"flame-eric"}; extra = undefined
I/Gecko   (   84): -- SystemMessageInternal 1410374383774 : Acquiring a CPU wake lock for page key = N1mFHp75Jx2zqEIlQ8WqGIamK7k=
I/Gecko   (   84): -- SystemMessageInternal 1410374383778 : Returned status of sending message: 2
I/Gecko   (   84): -- SystemMessageInternal 1410374383779 : _getMessageConfigurator for type: bluetooth-pairing-request
I/Gecko   (   84): -- SystemMessageInternal 1410374383783 : Asking to open {"pageURL":"app://settings.gaiamobile.org/index.html#root","manifestURL":"app://settings.gaiamobile.org/manifest.webapp","type":"bluetooth-pairing-request","onlyShowApp":false,"showApp":false}
I/Gecko   ( 2730): -- SystemMessageManager 1410374387238 : init
I/Gecko   ( 2730): -- SystemMessageManager 1410374387249 : done
I/Gecko   (   84): -- SystemMessageInternal 1410374387250 : Got Register from app://settings.gaiamobile.org/index.html#root @ app://settings.gaiamobile.org/manifest.webapp
I/Gecko   (   84): -- SystemMessageInternal 1410374387251 : listeners for app://settings.gaiamobile.org/manifest.webapp innerWinID 4
I/Gecko   ( 2730): -- SystemMessageManager 1410374387253 : set message handler for [activity] [xpconnect wrapped nsIDOMSystemMessageCallback]
I/Gecko   (   84): -- SystemMessageInternal 1410374387258 : received SystemMessageManager:GetPendingMessages activity for app://settings.gaiamobile.org/index.html#root @ app://settings.gaiamobile.org/manifest.webapp
I/Gecko   ( 2730): -- SystemMessageManager 1410374387351 : receiveMessage SystemMessageManager:GetPendingMessages:Return for [activity] with manifest URL = app://settings.gaiamobile.org/manifest.webapp and page URL = app://settings.gaiamobile.org/index.html#root
I/Gecko   (   84): 
I/Gecko   (   84): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
I/Gecko   (   84): 
I/Gecko   (   84): -- SystemMessageInternal 1410374389538 : Got child-process-shutdown from [object ChromeMessageSender]
I/Gecko   (   84): -- SystemMessageInternal 1410374389546 : remove the listener for app://settings.gaiamobile.org/manifest.webapp
I/Gecko   ( 2751): ###################################### forms.js loaded
I/Gecko   ( 2751): ############################### browserElementPanning.js loaded
I/Gecko   ( 2751): ######################## BrowserElementChildPreload.js loaded

According to the symptom and the log, I believe this is the same as bug 989709. The only difference is that an error dialog saying "Unable to pair with the device. Check that the PIN is correct." would be shown in this case, but this is not mentioned in bug 989709. In fact I think this may also happen in the case of bug 989709. The dialog shows because Gaia gets a "bluetooth-cancel" system message, which would be sent from Gecko when a pairing request has expired.

Mark this depend on bug 915611 to make the bug get higher priority.

Comment 15

[James Zhang (Spreadtrum)]

(In reply to Joe Cheng [:jcheng] from comment #13)
> hi James, can you please have your team to look at
> https://bugzilla.mozilla.org/show_bug.cgi?id=989742#c7? base on the STR and
> our investigation, we do not believe settings app is killed. thanks

Loop Xinhe.

Comment 16

[Xinhe Yan]

10961 01-01 00:41:05.680   700   700 D hciops  : user_confirm_request hci0
10962 01-01 00:41:05.680   700   700 D hciops  : user_confirm_request 1
10963 01-01 00:41:05.680   700   700 D hciops  : user_confirm_request 2
10964 01-01 00:41:05.680   700   700 D hciops  : user_confirm_request 3
10965 01-01 00:41:05.680   700   700 D hciops  : btd_event_user_confirmbtd_event_user_confirmbtd_event_user_confirm
10966 01-01 00:41:05.680   700   700 D hciops  : Calling Agent.RequestConfirmation: name=:1.0, path=/B2G/bluetooth/remote_device_agent, passkey=184388
10967 01-01 00:41:05.680   700   700 D hciops  : confirmation_request_new send dbus msg
10968 01-01 00:41:05.680   616   705 E GeckoBluetooth: AgentEventFilter: AgentEventFilter: /B2G/bluetooth/remote_device_agent, RequestConfirmation
10969 01-01 00:41:05.680   616   705 E GeckoBluetooth: AgentEventFilter: [AgentEventFilter] receive RequestConfirmation
10970 01-01 00:41:05.690   616   616 E GeckoBluetooth: Notify: [S] Notify: RequestConfirmation
11146 01-01 00:41:44.100   700   700 D hciops  : user_confirm_request hci0
11147 01-01 00:41:44.100   700   700 D hciops  : user_confirm_request 1
11148 01-01 00:41:44.100   700   700 D hciops  : user_confirm_request 2
11149 01-01 00:41:44.110   700   700 D hciops  : user_confirm_request 3
11150 01-01 00:41:44.110   700   700 D hciops  : btd_event_user_confirmbtd_event_user_confirmbtd_event_user_confirm
11151 01-01 00:41:44.110   700   700 D hciops  : Calling Agent.RequestConfirmation: name=:1.0, path=/B2G/bluetooth/remote_device_agent, passkey=870264
11152 01-01 00:41:44.110   700   700 D hciops  : confirmation_request_new send dbus msg
11153 01-01 00:41:44.110   616   705 E GeckoBluetooth: AgentEventFilter: AgentEventFilter: /B2G/bluetooth/remote_device_agent, RequestConfirmation
11154 01-01 00:41:44.110   616   705 E GeckoBluetooth: AgentEventFilter: [AgentEventFilter] receive RequestConfirmation
11155 01-01 00:41:44.120   616   616 E GeckoBluetooth: Notify: [S] Notify: RequestConfirmation
11226 01-01 00:41:57.190   616   616 E GeckoBluetooth: SetPairingConfirmationInternal: [SetPairingConfirmationInternal]
11227 01-01 00:41:57.190   616   616 E GeckoBluetooth: SetPairingConfirmationInternal: [SetPairingConfirmationInternal] confirm is b
11228 01-01 00:41:57.260   616   616 E GeckoBluetooth: SetPairingConfirmationInternal: [SetPairingConfirmationInternal] 1111
11229 01-01 00:41:57.260   616   616 E GeckoBluetooth: SetPairingConfirmationInternal: [SetPairingConfirmationInternal]2222
11230 01-01 00:41:57.290   616   616 E GeckoBluetooth: SetPairingConfirmationInternal: [SetPairingConfirmationInternal]3333
11237 01-01 00:41:57.440   700   700 D hciops  : confirm_replyconfirm_replyconfirm_reply
11238 01-01 00:41:57.460   700   700 D hciops  :  hciops_confirm_reply hci0 dba 00:02:5B:12:58:E7 success 1

This time we found gecko take more than 20 seconds to show user_confirm window.
This will cause pair timeout.
But after that pair success one time. The time is 13 seconds.

Comment 17

[James Zhang (Spreadtrum)]

I think it's not OOM issue, who can take a look?

Comment 18

[James Zhang (Spreadtrum)]

(In reply to James Zhang from comment #17)
> I think it's not OOM issue, who can take a look?

Eric, please comment here.

Comment 19

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

I just tried the latest Tarako build and I got totally different result from what I commented in comment 14. Bluetooth app and Settings app became very easy to be killed while reproduction.

Nice value of Settings app process is 7 (BACKGROUND_PERCEIVABLE) when Gaia received the system message "bluetooth-pairing-request" in connectivity.js. After that, nice was adjusted to 18 (BACKGROUND) and it got killed almost right away.

The symptom I mentioned above looks like an OOM issue.

Comment 20

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

Talked to Ting from Performance team. since Tarako has limited memory, if users try to launch Settings app when Gallery app exists, low-priority one may be killed.

To solve this, I would like to raise a proposal for 1.3T: move out pairing related implementation from Settings app.

Currently whenever Bluetooth pairing takes place, Settings app would been launched in order to deal with pairing requests. However Settings app is too heavy for the whole system and we should do pairing process in a more light-weight process to avoid OOM problem. We could move it to Bluetooth app, System app, or even a brand new 'Bluetooth pairing' app.

ni? settings peer Arthur to see if he has a better idea.

Comment 21

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

I have to say it is risky to move the pairing request handling from Settings app to Bluetooth app. Given the current schedule we may not have enough time to solve the potential regressions.

Comment 22

[Steven Yang [:styang]]

Hi Eric, What's our next step?

Comment 23

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

My suggestion is to create a pairing app which would only be launched while it's in bt-pairing process or move out the pairing part from Settings app to System app. These two ways both need a full testing to ensure the correctness. Actually I raised the same proposal in comment 20 and Arthur mentioned his worries in comment 21.

If we're going to do this, we may need a Gaia developer to dedicate on this since it's not simply fixing a bug but modifying architecture.

Comment 24

[Evelyn Hung]

How about restrict our scenario to "only transfer files to paired devices"? 
I think it might be not so risky for tarako, compare to create a pairing app or moving the whole pairing logic to system app.

@Marvin, what do you think?

Comment 25

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

Just make some tests for Bluetooth file transfer ability.

1. Does Bluetooth file transfer work fine after the two devices are paired?
Ans: Yes, it’s working fine in sending/receiving case.

2. Does the pairing dialog show again if our device is pairing, the receiver device is unpaired?
Ans: No, it looks like that the pairing process is finished in silent. And the file is transferred successfully.

3. Could we receive "bluetooth-pairing-request” if there is an app running in the foreground?
Ans: No. I try two test case.

a. Gallery app in the foreground, Settings is launched in the background. But Settings app is killed by LMK before it receive "bluetooth-pairing-request”.
b. Clock app in the foreground, Settings is launched in the background. But Settings app is killed by LMK before it dispatch CustomEvent for "bluetooth-pairing-request”.

===== Build Version =====
Gaia      68e072af2348c46fbff8a35d99ff10caeab16880
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/a8cc1aaec6a3
BuildID   20140420164002
Version   28.1
ro.build.version.incremental=eng.cltbld.20140415.201139
ro.build.date=Tue Apr 15 20:11:46 EDT 2014

Comment 26

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

According to the symptom in comment 25, the problem here is relative with pairing process. Settings app will be killed in launching time while a pairing request is coming. And it’s very easy able to reproduce while there is a running app in the foreground.

Since the pairing process is located in Setting app, we propose to migrate pairing flow from Settings to Bluetooth app. And the action item would be as following.

1. Beacause we have to ensure the pairing process not be killed. We have to set Bluetooth app be in-process app.
2. Bluetooth app should be close normally as a window while the pairing flow is finished.

Any suggest in this solution, feel free to comment here. Thanks.

Comment 27

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

Yes, thanks for writing down what we discussed. Moving things to a in-process app is better than moving everything to System app itself since it's memory is arguably more recoverable, and help System app in terms of keeping the architecture sane.

Comment 28

[[:fabrice] Fabrice Desré]

Tim, do you mean writing a new app, but load it in-process like we did for the callscreen app? I would be ok with that.

Comment 29

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #27)
> Yes, thanks for writing down what we discussed. Moving things to a
> in-process app is better than moving everything to System app itself since
> it's memory is arguably more recoverable, and help System app in terms of
> keeping the architecture sane.

+1 as callscreen app.

Comment 30

[Marvin Khoo [:Marvin_Khoo]]

guess there is discussion on solution, thus, remove ni from me.

Comment 31

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

(In reply to Fabrice Desré [:fabrice] from comment #28)
> Tim, do you mean writing a new app, but load it in-process like we did for
> the callscreen app? I would be ok with that.

Ian is working on making Bluetooth File Transfer app into a in-proc Bluetooth app (that handles both pairing and file transfer).

Comment 32

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

Attachment: WIP of pull request 18522

The major changes of WIP are as following.
* Migrate pairing process from Settings app to Bluetooth app.
* Enabled Bluetooth app run in-process.
* There is no way to identify pairing process in active/passive mode.
* Some unfinished work on GitHub.

I do some test for enabled/disable in-process for Bluetooth app. Although I disabled Bluetooth running in-process, Bluetooth file transfer is still working fine.

* Enabled:
  - Looks smooth and immediately for me.
  - The foreground app is still alive.

* Disabled:
  - Pairing dialog is showing up with delay 4~6 secs.
  - The foreground app(Settings, Music, ...) will be killed. It might confused a user after he/she just paired a remote device in Settings app.

Tim and Fabrice, could you please give some feedback in the WIP? Thanks.

Comment 33

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

Comment on attachment 8410193 [details] [review]
WIP of pull request 18522

I tried to understand how it works but it seems it would be better for Settings owner/peer to look at it instead.

Good work. I think we should land on master too to offload Settings app (without the in-proc switch), but you and Settings developers owns the decision on this one. :)

Comment 34

[[:fabrice] Fabrice Desré]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #33)
> Comment on attachment 8410193 [details] [review]
> WIP of pull request 18522
> 
> I tried to understand how it works but it seems it would be better for
> Settings owner/peer to look at it instead.
> 
> Good work. I think we should land on master too to offload Settings app
> (without the in-proc switch), but you and Settings developers owns the
> decision on this one. :)

+1

Comment 35

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

Comment on attachment 8410193 [details] [review]
WIP of pull request 18522

Evelyn and Arthur, 

The patch here is ready for reviewing process. I have updated it for fixing Bluetooth app in card view. Could you please help to review my pull request? Thanks.

Comment 36

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

(In reply to Ian Liu [:ianliu] from comment #35)
> Comment on attachment 8410193 [details] [review]
> WIP of pull request 18522
> 
> Evelyn and Arthur, 
> 
> The patch here is ready for reviewing process. I have updated it for fixing
> Bluetooth app in card view. Could you please help to review my pull request?
> Thanks.
Update: Manifest change, put "onpair.html" split into "message.html" and "onpair.html". Once Bluetooth app receive system message, the message will be handled via "message.html" first.

Comment 37

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

Comment on attachment 8410193 [details] [review]
WIP of pull request 18522

r=me with the nits addressed, thank you for working on this!

Comment 38

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

(In reply to Arthur Chen [:arthurcc] from comment #37)
> Comment on attachment 8410193 [details] [review]
> WIP of pull request 18522
> 
> r=me with the nits addressed, thank you for working on this!

Update for nits revised.

Comment 39

[Evelyn Hung]

Comment on attachment 8410193 [details] [review]
WIP of pull request 18522

also good to me. I saw you've addressed my comments. Thanks!

Comment 40

[Evelyn Hung]

Comment on attachment 8410193 [details] [review]
WIP of pull request 18522

clear feedback.

Comment 41

[Evelyn Hung]

merged to 1.3t:

https://github.com/mozilla-b2g/gaia/commit/d140b02e65c78f64281258c66f5b7f69bcfc4474

Hey Ian,

I think you may need to make another patch for master as Tim suggested in comment 33.
Leave a ni flag to remind you.

Comment 42

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

Evelyn and Arthur, thanks for your reviewing effort with patient. For Gaia/master, I'm working in this pull request(https://github.com/mozilla-b2g/gaia/pull/18621). I try to disable in-proc for BT app. But I get a black screen while a user share pictures and turn on Bluetooth in BT app. Still trace the problem, and add unit test for additional .js file. Thanks.

Comment 43

[Evelyn Hung]

(In reply to Ian Liu [:ianliu] from comment #42)
> Evelyn and Arthur, thanks for your reviewing effort with patient. For
> Gaia/master, I'm working in this pull
> request(https://github.com/mozilla-b2g/gaia/pull/18621). I try to disable
> in-proc for BT app. But I get a black screen while a user share pictures and
> turn on Bluetooth in BT app. Still trace the problem, and add unit test for
> additional .js file. Thanks.

Ian, please file another bug for your master change so we can finish here. Thanks.

Comment 44

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

Sure, let's tracking Gaia/master patch via bug 1003739.

Comment 45

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This issue is fixed on today's Tarako 1.3t build


1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140430014008
Gaia: f9b62bd1135f4edf8317fff1c2947b9d99438d79
Gecko: ba50f734b815
Version: 28.1
Firmware Version: sp6821