Closed Bug 989742 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3T+, b2g-v1.3 unaffected, b2g-v1.3T verified, b2g-v1.4 unaffected)

RESOLVED FIXED
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.3T --- verified
b2g-v1.4 --- unaffected

People

(Reporter: bli, Assigned: iliu)

References

Details

(Whiteboard: OOM, 1.3tarakorun2, [sprd295240], [partner-blocker])

Attachments

(3 files)

4.33 KB, text/x-log
Details
88.25 KB, text/x-log
Details
46 bytes, text/x-github-pull-request
jj.evelyn
: review+
arthurcc
: review+
fabrice
: feedback+
timdream
: feedback+
Details | Review
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."
Hi! Eric,

Could BT team help on this case?
Thanks

--
Keven
blocking-b2g: --- → 1.3T?
Flags: needinfo?(echou)
Sure. I'll investigate first.
Component: Gaia::Bluetooth File Transfer → Bluetooth
Flags: needinfo?(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.
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
(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 ?
Assignee: nobody → echou
blocking-b2g: 1.3T? → 1.3T+
Keywords: qawanted
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
[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
Flags: needinfo?(xinhe.yan)
Flags: needinfo?(bli)
It's not bluetooth issue, it's LMK issue.
Setting apps is killed by LMK.
Assignee: echou → tchou
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
Attached file hcidump log
Flags: needinfo?(bli)
Attached file logcat
(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."
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
Assignee: tchou → nobody
Flags: needinfo?(james.zhang)
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.
Depends on: 915611
Keywords: qawanted
(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.
Flags: needinfo?(james.zhang)
Assignee: nobody → xinhe.yan
Whiteboard: OOM → OOM [POVB]
Whiteboard: OOM [POVB] → OOM [POVB], 1.3tarakorun2
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.
Flags: needinfo?(xinhe.yan)
I think it's not OOM issue, who can take a look?
Flags: needinfo?(ttsai)
(In reply to James Zhang from comment #17)
> I think it's not OOM issue, who can take a look?

Eric, please comment here.
Flags: needinfo?(styang)
Flags: needinfo?(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.
Flags: needinfo?(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.
Flags: needinfo?(arthur.chen)
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.
Flags: needinfo?(arthur.chen)
Flags: needinfo?(styang)
Whiteboard: OOM [POVB], 1.3tarakorun2 → OOM, 1.3tarakorun2
Hi Eric, What's our next step?
Flags: needinfo?(styang)
Flags: needinfo?(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.
Flags: needinfo?(echou)
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?
Flags: needinfo?(mkhoo)
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
Whiteboard: OOM, 1.3tarakorun2 → OOM, 1.3tarakorun2, [sprd295240]
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.
Flags: needinfo?(timdream)
Flags: needinfo?(fabrice)
Flags: needinfo?(styang)
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.
Flags: needinfo?(timdream)
Assignee: xinhe.yan → iliu
Component: Bluetooth → Gaia::Bluetooth File Transfer
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.
Flags: needinfo?(fabrice)
(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.
guess there is discussion on solution, thus, remove ni from me.
Flags: needinfo?(mkhoo)
(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).
Summary: [Tarako][Bluetooth] Unable to pair devices when send files via bluetooth (Bluetooth was disabled before sending files) → [Tarako][Settings][Bluetooth] Unable to pair devices when a foreground app(not Settings app) is running.
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.
Attachment #8410193 - Flags: feedback?(timdream)
Attachment #8410193 - Flags: feedback?(fabrice)
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. :)
Attachment #8410193 - Flags: feedback?(timdream)
Attachment #8410193 - Flags: feedback?(ehung)
Attachment #8410193 - Flags: feedback+
(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
Attachment #8410193 - Flags: feedback?(fabrice) → feedback+
Whiteboard: OOM, 1.3tarakorun2, [sprd295240] → OOM, 1.3tarakorun2, [sprd295240], [partner-blocker]
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.
Attachment #8410193 - Flags: review?(ehung)
Attachment #8410193 - Flags: review?(arthur.chen)
(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 on attachment 8410193 [details] [review]
WIP of pull request 18522

r=me with the nits addressed, thank you for working on this!
Attachment #8410193 - Flags: review?(arthur.chen) → review+
(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 on attachment 8410193 [details] [review]
WIP of pull request 18522

also good to me. I saw you've addressed my comments. Thanks!
Attachment #8410193 - Flags: review?(ehung) → review+
Comment on attachment 8410193 [details] [review]
WIP of pull request 18522

clear feedback.
Attachment #8410193 - Flags: feedback?(ehung)
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(iliu)
Resolution: --- → FIXED
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.
Flags: needinfo?(iliu)
Flags: needinfo?(ttsai)
(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.
Flags: needinfo?(iliu)
See Also: → 1003739
Sure, let's tracking Gaia/master patch via bug 1003739.
Flags: needinfo?(iliu)
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
You need to log in before you can comment on or make changes to this bug.