[Dialer][USSD] Call Control Supplementary Service commands (Call Waiting, Call Deflection) result in improper confirmation text.

VERIFIED FIXED in Firefox OS v2.2

Status

Firefox OS
Gaia::Dialer
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Marty, Assigned: gsvelto)

Tracking

(Blocks: 2 bugs, {regression})

unspecified
2.2 S12 (15may)
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.1S unaffected, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [caf priority: p2][CR 831602][3.0-Daily-Testing])

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8567379 [details]
logcat-Call-Control.txt

Description:
Using Call Control commands within calls results in a generic screen that simply reads 'smCallControl' instead of having a proper user-facing confirmation message.

Repro Steps:
1) Update a Flame to 20150220010206
2) Call the DUT from another device
3) Answer the call, dismiss the call screen with the Home button, and open the Dialer app.
4) Enter 1' and tap 'Send'

Actual:
The call is properly ended, but the user is presented with a generic confirmation screen that reads 'smCallControl'

Expected:
The user is presented with a proper confirmation message for the command used.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150220010206
Gaia: e4f7c67378e33e83f88d38ddb4a6c2cabf1423c3
Gecko: 1b4c5daa7b7a
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Repro frequency: 5/5
See attached: screenshot, logcat
(Reporter)

Comment 1

3 years ago
Created attachment 8567380 [details]
Call-Control-Screenshot.png
(Reporter)

Comment 2

3 years ago
This issue DOES occur in Flame 2.2.
The call is properly ended, but the user is presented with a generic confirmation screen that reads 'smCallControl'

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150219002504
Gaia: ce79d35b92261e7cbfeaefebf87859ebeb0979b4
Gecko: 159a3907b959
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

------------------------------

This issue does NOT occur in Flame 2.1 builds.
The call control command does not function, and the user is presented with a 'Session Expired' message.

Environmental Variables:
Device: Flame 2.1 (319MB)(Full Flash)
Build ID: 20150210002200
Gaia: 7dd130a312f12c89b2d41948f8557effa56afbf6
Gecko: 2de03dfa9aac
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(jlorenzo)
(Assignee)

Comment 4

3 years ago
What would be the correct behavior here? A generic message such as "Command successfully executed", a specific one for each command ("Call ended", etc...) or no message at all?
Flags: needinfo?(mshuman)
Even though it's seems not clear enough, the error got a bit less generic. I don't think we can block on this bug.
Flags: needinfo?(jlorenzo)
(Reporter)

Comment 6

3 years ago
(In reply to Gabriele Svelto [:gsvelto] from comment #4)
> What would be the correct behavior here? A generic message such as "Command
> successfully executed", a specific one for each command ("Call ended",
> etc...) or no message at all?

I feel like either the generic or specific message options would be fine.  My understanding is that most USSD functionality is supposed to have a message present to indicate success/failure, so I'm not sure the messages should be removed.  I personally would think that having a specific message for each command would probably help users discover and understand the feature functionality.
Flags: needinfo?(mshuman)
(Assignee)

Updated

3 years ago
Blocks: 1036516
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1159977
(Assignee)

Comment 8

3 years ago
Moving flags and dependencies over from bug 1159977.
Blocks: 1063044
blocking-b2g: --- → 2.2?
(Assignee)

Comment 9

3 years ago
I did some quick testing and neither Android nor iOS show any message but rather just execute the action associated with the code. I'd be inclined to do the same.
Created attachment 8600337 [details] [review]
[gaia] gabrielesvelto:bug-1135284-call-control-supplementary-service-commands > mozilla-b2g:master
(Assignee)

Comment 11

3 years ago
Comment on attachment 8600337 [details] [review]
[gaia] gabrielesvelto:bug-1135284-call-control-supplementary-service-commands > mozilla-b2g:master

Real simple fix for this. This implements the same behavior that I've found on iOS and Android devices. In response to a call control supplementary service command we first show the MMI overlay UI while we wait for the result then we hide it without showing the result. I think this UX is reasonable as the effect of the command is readily visible (e.g. the call ends and the status change appears in the statusbar, etc...).

I've added a unit-test to cover this case and cleaned up the code which dealt with a race-condition I had previously encountered. There's no need to track the fade animation start/end; adding the event listener for animationend before starting the animation is sufficient to ensure that the listener will always trigger.
Attachment #8600337 - Flags: review?(thills)

Updated

3 years ago
Whiteboard: [3.0-Daily-Testing] → [CR 831602][3.0-Daily-Testing]

Updated

3 years ago
Whiteboard: [CR 831602][3.0-Daily-Testing] → [caf priority: p2][CR 831602][3.0-Daily-Testing]
i guess we'd also like to hear from UX.
Flags: needinfo?(cawang)
Is this a cert blocker from CAF?
Flags: needinfo?(pgravel)
Comment on attachment 8600337 [details] [review]
[gaia] gabrielesvelto:bug-1135284-call-control-supplementary-service-commands > mozilla-b2g:master

Hi Gabriele,

This looks good (though I think we still are waiting for UX before landing, right?)

One thing I wanted to mention is that whether since we are making changes if we should get rid of the mozL10n.get in mmi_ui.js since that is deprecated.

Thanks,

-tamara
Attachment #8600337 - Flags: review?(thills) → review+
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Target Milestone: --- → 2.2 S12 (15may)
(Assignee)

Comment 15

3 years ago
(In reply to Tamara Hills [:thills] from comment #14)
> This looks good (though I think we still are waiting for UX before landing,
> right?)

Yes, let's wait for UX first.

> One thing I wanted to mention is that whether since we are making changes if
> we should get rid of the mozL10n.get in mmi_ui.js since that is deprecated.

Yes but I wanted to do that separately as part of bug 1093266.

Updated

3 years ago
Flags: needinfo?(pgravel) → needinfo?(anshulj)

Comment 16

3 years ago
Wesley, since we already support this feature and a PR is already available from Gabriele, I would request to consider this for 2.2 for a much better user experience. Regarding certification blocker, that is usually an operator's call.
Flags: needinfo?(anshulj)
Hi

I think this one looks good. I'm fine with hiding the result message. Because in this case, user knows the command and executes it by himself and the outcome is obviously observed. So I'd say, it's good to go! Thanks!
Flags: needinfo?(cawang)
Triage:
We already past FC, and we shipped before, not being a certification blocker. So we will not add it to 2.2, despite that the patch doesn't look risky, because we are past FC and as we understand from comment 16 is a nice to have feature, not a CAF blocker.
blocking-b2g: 2.2? → ---
According to comment 2, this was not shipped before. I have compared:
- v2.1 behaviour: "Unknown application" message--> expected behaviour (build Gecko-862f60d.Gaia-b4a03b7)
- master: "smCallControl" message --> not expected (build Gecko-a73745d.Gaia-bb65538)

It will be a certification blocker for v2.2. Renominating. It is a regression.
blocking-b2g: --- → 2.2?
status-b2g-v2.1: --- → unaffected
(Assignee)

Comment 20

3 years ago
(In reply to Carrie Wang [:carrie] from comment #17)
> I think this one looks good. I'm fine with hiding the result message.
> Because in this case, user knows the command and executes it by himself and
> the outcome is obviously observed. So I'd say, it's good to go! Thanks!

Thanks Carrie, I'm landing the PR then.
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/5e8c758ec9ab0034614937fb43e09f4eb02c7991

Updated

3 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(In reply to Beatriz Rodríguez [:brg] from comment #19)
> According to comment 2, this was not shipped before. I have compared:
> - v2.1 behaviour: "Unknown application" message--> expected behaviour (build
> Gecko-862f60d.Gaia-b4a03b7)

Comms triage: According to comment 2 and testing from our side[1], "Session expired" is displayed, not "unknown application". We're not sure why this was an expected behavior and why this could be considered as a regression.
As we're now after feature complete, we think it's more prudent to keep the current behavior. Please renominate if you disagree.

[1] Build ID               20150506161202
Gaia Revision          b4a03b7ee61de5a479b3cf0916f47e91a43b0f50
Gaia Date              2015-04-30 21:31:55
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4493015380ab
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20141120.194707
Firmware Date          Thu Nov 20 19:47:17 EST 2014
Bootloader             L1TC00011880
blocking-b2g: 2.2? → ---
(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #22)
> (In reply to Beatriz Rodríguez [:brg] from comment #19)
> Comms triage: According to comment 2 and testing from our side[1], "Session
> expired" is displayed, not "unknown application". We're not sure why this
> was an expected behavior and why this could be considered as a regression.
> As we're now after feature complete, we think it's more prudent to keep the
> current behavior. Please renominate if you disagree.

This is a regression in the behaviour from v2.1 to v2.2.
"smCallControl" message means nothing for the user while "unknown application or session expired" are related to USSD responses seen in other situations.
blocking-b2g: --- → 2.2?
Comms triage: Blocking based on comment 23.
blocking-b2g: 2.2? → 2.2+

Comment 25

3 years ago
Comment on attachment 8600337 [details] [review]
[gaia] gabrielesvelto:bug-1135284-call-control-supplementary-service-commands > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:
Attachment #8600337 - Flags: approval-gaia-v2.2?
(Assignee)

Comment 26

3 years ago
I'm providing the approval request comment

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): MMI support
[User impact] if declined: When using call control supplementary service commands a overlay with an untranslated message (and an obscure one too) is shown when no one should
[Testing completed]: Tested on a device and on the emulator
[Risk to taking this patch] (and alternatives if risky): Risk is limited, there's only three lines worth of changes and they are part of a well tested piece of code designed to handle these return codes.
[String changes made]: None

Updated

3 years ago
Keywords: regression

Comment 27

3 years ago
Comment on attachment 8600337 [details] [review]
[gaia] gabrielesvelto:bug-1135284-call-control-supplementary-service-commands > mozilla-b2g:master

Approving given this is CAF blocker and regression.
Attachment #8600337 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+

Comment 28

3 years ago
Dear Martin,
Could you please help to verify the fix on master?and also on 2.2 after the patch land there?
Thanks!
status-b2g-v2.1S: --- → unaffected
status-b2g-master: affected → fixed
Flags: needinfo?(mshuman)
Keywords: verifyme
(Reporter)

Comment 29

3 years ago
This issue is verified fixed in the latest Master Flame build.
The call is properly ended by the control code, and there is no confirmation message.

Environmental Variables:
Device: Flame Master (319MB)(Full Flash)
Build ID: 20150512010209
Gaia: 6089234ace8b294a8feef064387604bae16254e3
Gecko: 502e1a5e722f
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Leaving NI on myself to verify 2.2 once it lands.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-master: fixed → verified
Flags: needinfo?(pbylenga)
v2.2: https://github.com/mozilla-b2g/gaia/commit/39d854514a57984692c3104c65606fdc253ba520
status-b2g-v2.2: affected → fixed
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
(Reporter)

Comment 31

3 years ago
This issue is verified fixed in the latest 2.2 Flame build.
The call is properly ended by the control code, and there is no confirmation message.

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150513002507
Gaia: e048df68f6f4853b5826a8816e143d95258149de
Gecko: 0e6b4aab2b94
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-v2.2: fixed → verified
Flags: needinfo?(mshuman) → needinfo?(pbylenga)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
You need to log in before you can comment on or make changes to this bug.