Forward When Unanswered switch non-functional

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::Dialer
RESOLVED WORKSFORME
2 years ago
2 years ago

People

(Reporter: sxean, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v2.2 affected, b2g-v2.5 affected, b2g-master affected)

Details

(Whiteboard: [2.6-Daily-Testing][Spark], URL)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8689190 [details]
Call Forwarding When Unanswered.txt

Call forwarding switch for "Forward when Unanswered", stays enabled after attempted disable. 

Repro Steps:
1) Update a Aries to 20151118151339
2) Go to Call Settings > Call Forwarding > With ALWAYS FORWARD disabled go to: 
"Forward when Unanswered". 
3) Switch OFF "Forward when Unanswered". Press OK.
4) Observe Message and press Continue. 
5) Observe that the Forward Switch is re-enabled. 
6) Also happens with the "Forward when Busy", and "Forward when unreachable" Switches. 

Actual:
Call Forwarding confirmation message states: " Your operator does not support that operation" OR 
" Call settings error.", and the Forward When Unanswered button is re-enabled. 

Expected:
"Forward when Unanswered", "Forward when Busy", and "Forward when unreachable" Switches 
should stay dis-abled when switched off. 

Environmental Variables:
Device: Aries 2.6
Build ID: 20151118151339
Gaia: cba7e4b86361af31b153cfebaf99900e0b860f7b
Gecko: 1d6155d7e6c91fa5ec1ef6927f3d3a044187896d
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Repro frequency: (5/5)
See attached: ( video clip & logcat)

REPROS ON the Following Builds: 
Environmental Variables:
Device: Aries 2.5
BuildID: 20151112123156
Gaia: 240088d7a70dae41215ef61dd3fe3487709a4b65
Gecko: e1f0fe73bc84ad2103a5c661bdd15c16a47d4af5
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 44.0a2 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Environmental Variables:
Device: Flame 2.6
Build ID: 20151117030236
Gaia: 9473dbcbebf4e758a3b73200968efc69071b4312
Gecko: 898c2c656e4b156c323416ef0c859915f3fd2308
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20151109004552
Gaia: cf646c52bb947af28329b0a100df91d1b1f2a907
Gecko: 4eafef5b80f8985c94c4a067f130d37513e1a581
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Environmental Variables:
Device: Flame 2.2
BuildID: 20151117032501
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: e772f343b736
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
(Reporter)

Updated

2 years ago
status-b2g-v2.2: --- → affected
status-b2g-v2.5: --- → affected
status-b2g-master: --- → affected
Flags: needinfo?(jmercado)
(Reporter)

Updated

2 years ago
Summary: Forward When Unanswered switch non-functional. → Forward When Unanswered switch non-functional
Isabel should this block?
Flags: needinfo?(jmercado) → needinfo?(irios.mozilla)
Has this been tested with the same SIM than when it was working? 

There were several issues with the call forwarding in the past but finally it was working just wondering why it could be failing in 2.2 again. Let me investigate a little bit more also.
Thanks!
Flags: needinfo?(irios.mozilla)
Hi Sxean, has this issue happened with the same SIM that you always use to check this? 
I ask that because, please see bug 1029394 description, there are operators that may not allow to disable those options. The implementation were changed so that at least we could modify those fields but not to disable in case the operator does not allow that.

Would that be what you are seeing? Thanks
Flags: needinfo?(sleedavid)
(Reporter)

Comment 4

2 years ago
(In reply to Isabel Rios[:isabel_rios] from comment #3)
> Hi Sxean, has this issue happened with the same SIM that you always use to
> check this? 
> I ask that because, please see bug 1029394 description, there are operators
> that may not allow to disable those options. The implementation were changed
> so that at least we could modify those fields but not to disable in case the
> operator does not allow that.
> 
> Would that be what you are seeing? Thanks

Hi Isabel, 
This issue reproed on 3 different SIMS. It could be that the SIMS have the same
functionality however, my concern is with the way the UI handles the disabling
of the Features whether they're available or not. According to bug 1029394 I am 
not seeing the, "Your Operator does not support that Operation."  message. 

Just keep seeing the "Call settings error" message. Thank you.
Flags: needinfo?(sleedavid)
Hi Sxean,

I understand your concern, I tried with my sim cards but I cannot reproduce the problem, please see the video: https://youtu.be/ImBcqfVEspw. I always get "Your Operator does not support that Operation" when trying to turn it off. I can edit the number successfully but not to turn that setting off.
I think that is matching with comments in bug 1029394. But please let me know if you think otherwise.
I will try to find a developer how worked in that part so we can understand what could be happening.
Thanks!

Tested with Flame 2.6
Buildid: 20151124150228
Platform: 45.0a1
Gaia: e63c07af
Flags: needinfo?(sleedavid)
(Reporter)

Comment 6

2 years ago
(In reply to Isabel Rios[:isabel_rios] from comment #5)
> Hi Sxean,
> 
> I understand your concern, I tried with my sim cards but I cannot reproduce
> the problem, please see the video: https://youtu.be/ImBcqfVEspw. I always
> get "Your Operator does not support that Operation" when trying to turn it
> off. I can edit the number successfully but not to turn that setting off.
> I think that is matching with comments in bug 1029394. But please let me
> know if you think otherwise.
> I will try to find a developer how worked in that part so we can understand
> what could be happening.
> Thanks!
> 
> Tested with Flame 2.6
> Buildid: 20151124150228
> Platform: 45.0a1
> Gaia: e63c07af

Yes, please do keep me posted.
Flags: needinfo?(sleedavid)
Hi Gabriele,
Not sure you whether you took this part of call settings done by tef before. Could you please have a look to help us understand whether there is a bug in this part or what could be happening? 
If you are not the owner of this part, do you know who could help?
Thank you very much!
Flags: needinfo?(gsvelto)
I did some work on the call forwarding codes in the dialer but I'm not super-familiar with it. I've tried on my Flame using my Italian SIM card and I seem to encounter the same behaviour described in comment 0 with the "Forward when busy" and "Forward when unreachable" in that I cannot disable them when "Always Forward" is off. However I think this is enforced by the network and not an issue with our code, here's why.

I tried using USSD codes to setup those call forwarding options and I get similar results. For "Forward when busy" for example I did the following:

1. Type *#67# in the dialer and send to query the "forward when busy" status
2. The result screen shows call forwarding being active and pointing to a predefined number
3. Type #67# in the dialer and send to disable "forward when busy" functionality
4. The result screen shows that call forwarding has been disabled but...
5. Type *#67# in the dialer and send again to verify if the change is reflected in the network status
6. KO, call forwarding when busy is still active and points to the same number

I tried changing the number and that works correctly (**67*<your number here>#) but calling the disable (#67#) and erase (##67#) commands yield the same result: the number is reset to the carrier-provided default number and the service is *not* disabled.

So unless we have some bizarre issue inside the RIL that's causing the "service disable" commands to not being handled properly I'd say this is all expected behaviour dependent on your carrier.
Flags: needinfo?(gsvelto)
Hi Gabriele,
Thank you very much for your feedback. I will then close the bug as WFM but please if you, Sxean or someone think differently, feel free to re-open it.
Thanks!
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.