Closed Bug 995458 Opened 6 years ago Closed 6 years ago

[B2G][Tarako][Settings] 'Caller ID' and 'Call waiting' settings are not saved for individual SIM cards


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

Gonk (Firefox OS)
Not set


(blocking-b2g:1.3T+, b2g-v1.3 wontfix, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

1.4 S6 (25apr)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3 --- wontfix
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed


(Reporter: demerick, Assigned: arthurcc)




(Keywords: branch-patch-needed, Whiteboard: 1.3tarakorun2 [p=2] [sprd 311610])


(4 files)

If the user enters Call Settings with two SIM cards in the device they will get the option to choose which SIM they want to configure. After choosing a SIM, changing the 'Call waiting' or 'Caller ID' settings will change the settings for BOTH SIM cards.

Repro Steps:

Pre-requisites -  two active SIM cards

1) Update a Tarako to BuildID: 20140411004003 and insert two SIM cards
2) Tap 'Settings' from the home screen
3) Tap 'Call Settings' and tap 'SIM 1'
4) Wait for settings to load and enable 'Call waiting'
5) Tap the back arrow in the top left corner of the screen
6) Tap 'SIM 2' and disable 'Call waiting' after the settings load
7) Tap the back arrow in the top left corner of the screen
8) Tap 'SIM 1' and observe 'Call waiting' setting

SIM 1 'Call waiting' setting is changed 

Only SIM 2 'Call waiting' setting is changed

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140411004003
Gaia: 27a0e773e01eed74e20709bdcab6894469f42a72
Gecko: 257dd37da601
Version: 28.1
Firmware Version: SP8810

Repro frequency: 100%
Link to failed test case:
See attached: logcat, firewatch

Video URL:
bug 981989 hasn't landed in 1.3T.  I'm not sure the risk involved in taking it.  noming
blocking-b2g: --- → 1.3T?
This shouldn't block. A lot of the individual SIM management use cases for DSDS to my understanding was planned for 1.4, not 1.3.
IIRC, this is by design in 1.3, let's confirm with Arthur on the implementation of 1.3. if so, let's close this bug. thanks
Flags: needinfo?(arthur.chen)
Call waiting and caller ID should work in v1.3.
Flags: needinfo?(arthur.chen)
Looks like the fix hasn't landed in 1.3.  If it's by design in 1.3 then I guess we should close this off as a dup of bug 981989
Assignee: nobody → arthur.chen
triage: 1.3T+, after talking to arthur this is a bug.
blocking-b2g: 1.3T? → 1.3T+
Arthur, what's the fix plan here?
Flags: needinfo?(arthur.chen)
Flags: needinfo?(arthur.chen)
Whiteboard: 1.3tarakorun2 → 1.3tarakorun2 [ETA: 4/18]
Depends on: 997584
The caller id issue depends on bug 997584. However, I'm not able to reproduce the call waiting issue. (

Gaia      718a06816327fcb6a18095f677cfff4b86adc292
BuildID   20140415164003
Version   28.1 Apr 15 20:11:46 EDT 2014
Keywords: qawanted
Depends on: 997601
No longer depends on: 997601
I can reproduce it.
I have contacted Arthur, and gave the Tarako device.

Please re-mark QAwanted if anyone have further question.
Keywords: qawanted
While system is requesting network information(SIM1) then switch to the other SIM card (SIM2) settings, 
You will see SIM2's status synchronize the SIM1's status.
The unconfirmed network status causes the problem. (Bug 997584)
The call waiting issue is due to the latency of querying states from the carrier. If users try to navigate to the panel of another sim card before the query completed, the states of the previous sim card is displayed.
The patch tries to solve the UI refresh issue of sharing the same ui page across two sim cards. A context management mechanism helps ensure that the result of the last query is displayed on the UI. Jose, could you help review the patch? Thanks!
Attachment #8408861 - Flags: review?(josea.olivera)
Target Milestone: --- → 1.4 S6 (25apr)
(In reply to Arthur Chen [:arthurcc] from comment #13)
> Created attachment 8408861 [details]
> Link to

The patch LGTM but I'd like to test it on a real device. I'll test on a fugu device as I don't have a tarako one. Arthur, I'll get back to you ASAP. Thanks.
Comment on attachment 8408861 [details]
Link to

Thanks for the patch Arthur. Left a comment in the PR.

Note: Sadly I won't be able to test this patch on a DSDS device until next week. The device we have in the office is broken (doesn't not boot at all). I will test the work with a single ICC card device (Peak). Sorry for the inconveniences.
Attachment #8408861 - Flags: review?(josea.olivera)
Comment on attachment 8408861 [details]
Link to

The patch has been rewritten to address the issue you brought up. In the end I queue the async tasks and execute them in sequential order. And redundant tasks will not be executed as well.

Please use the w=1 url ( to check the patch, thanks!
Attachment #8408861 - Flags: review?(josea.olivera)
PR against v1.3t.
Attachment #8412386 - Flags: review?(josea.olivera)
Whiteboard: 1.3tarakorun2 [ETA: 4/18] → 1.3tarakorun2
Comment on attachment 8408861 [details]
Link to

This approach works like a charm, thanks for this Arthur. r=me

As I commented on previous comments I don't have a multi ICC card device so I tested this on peak. I really thrush Arthur and I don't think this patch brakes anything on a multi ICC card device.
Attachment #8408861 - Flags: review?(josea.olivera) → review+
Comment on attachment 8412386 [details]
Link to

This approach works like a charm as well, thanks for this Arthur. Tested on buri device running v1.3. r=me
Attachment #8412386 - Flags: review?(josea.olivera) → review+
Whiteboard: 1.3tarakorun2 → 1.3tarakorun2 [ETA: 4/30][p=2]
Arthur, what's the next step for this bug?

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #5)
> Looks like the fix hasn't landed in 1.3.  If it's by design in 1.3 then I
> guess we should close this off as a dup of bug 981989

should we switch to status-1.3 -> wontfix?
Flags: needinfo?(arthur.chen)
We need to support DSDS for call waiting and caller id restriction in v1.3. The proposed patch in comment 13 solves the call waiting part. The caller id restriction part is being handled in bug 997584. I'll mark this one as resolved once bug 997584 lands.

Joe, should we uplift this to v1.3?
Flags: needinfo?(arthur.chen) → needinfo?(jcheng)
ni? Bhavana / Fabrice on 1.3
Flags: needinfo?(jcheng)
Flags: needinfo?(fabrice)
Flags: needinfo?(bbajaj)
I'm fine with taking that on 1.3, but you need to ask approval on the patch.
Flags: needinfo?(fabrice)
We haven't seen this as an IOT/ cert blocker and hence leaving out for 1.3.
Flags: needinfo?(bbajaj)
master: 7a638fc49d62c6c8cf0892b13b2c20c54e3d67bb
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: 1.3tarakorun2 [ETA: 4/30][p=2] → 1.3tarakorun2 [p=2]
v1.3t: 557b6f81bbf792f99c58fe663441a9f8b7f90a4a

Tested with the build 20140511164002, it still failed on the caller id part. As gaia and gecko have addressed the problem, hsinyi suspects there is a problem on the modem side. Land the gaia patch first.
add sam
Please check Comment 26
Flags: needinfo?(sam.hua)
(In reply to ying.xu from comment #27)
> add sam
> Please check Comment 26

You could also refer to for log.
Flags: needinfo?(sam.hua)
Whiteboard: 1.3tarakorun2 [p=2] → 1.3tarakorun2 [p=2] [sprd 311610]
Thanks all.
Verified it.

* Build information:
 - Build ID  20140519164002
 - Gaia      917174ee3812a43758bf43f7ba5f9416dcdb2ca8
 - Gecko     a3a14fb5ad51
Hi Arthur,

Is this patch landed in v1.4?
Flags: needinfo?(arthur.chen)
No, it is not. And all the dependent bugs are not in v1.4 as well.
Flags: needinfo?(arthur.chen)
Whiteboard: 1.3tarakorun2 [p=2] [sprd 311610] → 1.3tarakorun2 [p=2] [sprd 311610][1.4-approval-needed]
Comment on attachment 8408861 [details]
Link to

Hi Preeti,

Per our discussion during the meeting, I send the approval request for this fix to be uplifted to v1.4. For the approval comment, please refer to bug 997601 comment here
Attachment #8408861 - Flags: approval-gaia-v1.4?(praghunath)
(In reply to Ivan Tsay (:ITsay) from comment #32)
> Comment on attachment 8408861 [details]
> Link to
> Hi Preeti,
> Per our discussion during the meeting, I send the approval request for this
> fix to be uplifted to v1.4. For the approval comment, please refer to bug
> 997601 comment here

Meant to say comment in bug 997601
Attachment #8408861 - Flags: approval-gaia-v1.4?(praghunath) → approval-gaia-v1.4+
Needs rebasing for v1.4 uplift.
Flags: needinfo?(arthur.chen)
Whiteboard: 1.3tarakorun2 [p=2] [sprd 311610][1.4-approval-needed] → 1.3tarakorun2 [p=2] [sprd 311610]
The patch depends on the patch of bug 997601. I'll provide a PR against v1.4 after bug 997601 lands on v1.4.
Flags: needinfo?(arthur.chen)
Any time now :)
Flags: needinfo?(arthur.chen)
Attached file PR against v1.4
Note that we can land the patch when it passes gaia try but should not mark the bug as fixed until bug 997584 gets fixed on v1.4. :)
Flags: needinfo?(arthur.chen)
I'm very confused on the uplift/blocking/approval status of all these bugs, so it's probably going to be best if you just handle them at this point.
Comment on attachment 8442553 [details]
PR against v1.4

NOTE: Please see to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): DSDS feature
[User impact] if declined: See user impact on comment 39
[Testing completed]: verified in bug 995458
[Risk to taking this patch] (and alternatives if risky): Low, since QA already the test cases on this 
[String changes made]:No change
Attachment #8442553 - Flags: approval-gaia-v1.4?(praghunath)
Attachment #8442553 - Flags: approval-gaia-v1.4?(praghunath) → approval-gaia-v1.4+
You need to log in before you can comment on or make changes to this bug.