Closed
Bug 1135284
Opened 10 years ago
Closed 9 years ago
[Dialer][USSD] Call Control Supplementary Service commands (Call Waiting, Call Deflection) result in improper confirmation text.
Categories
(Firefox OS Graveyard :: Gaia::Dialer, defect)
Tracking
(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.1S unaffected, b2g-v2.2 verified, b2g-master verified)
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | unaffected |
b2g-v2.1S | --- | unaffected |
b2g-v2.2 | --- | verified |
b2g-master | --- | verified |
People
(Reporter: Marty, Assigned: gsvelto)
References
Details
(Keywords: regression, Whiteboard: [caf priority: p2][CR 831602][3.0-Daily-Testing])
Attachments
(3 files)
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•10 years ago
|
||
Reporter | ||
Comment 2•10 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)
Comment 3•10 years ago
|
||
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(jlorenzo)
Assignee | ||
Comment 4•10 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)
Comment 5•10 years ago
|
||
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•10 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•9 years ago
|
Blocks: dialer-most-wanted
Assignee | ||
Comment 8•9 years ago
|
||
Moving flags and dependencies over from bug 1159977.
Blocks: CAF-v2.2-metabug
blocking-b2g: --- → 2.2?
Assignee | ||
Comment 9•9 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.
Comment 10•9 years ago
|
||
Assignee | ||
Comment 11•9 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•9 years ago
|
Whiteboard: [3.0-Daily-Testing] → [CR 831602][3.0-Daily-Testing]
Updated•9 years ago
|
Whiteboard: [CR 831602][3.0-Daily-Testing] → [caf priority: p2][CR 831602][3.0-Daily-Testing]
Comment 14•9 years ago
|
||
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+
Updated•9 years ago
|
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Target Milestone: --- → 2.2 S12 (15may)
Assignee | ||
Comment 15•9 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.
Comment 16•9 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)
Comment 17•9 years ago
|
||
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)
Comment 18•9 years ago
|
||
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? → ---
Comment 19•9 years ago
|
||
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•9 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•9 years ago
|
Keywords: checkin-needed
Comment 21•9 years ago
|
||
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/5e8c758ec9ab0034614937fb43e09f4eb02c7991
Updated•9 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 22•9 years ago
|
||
(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? → ---
Comment 23•9 years ago
|
||
(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?
Comment 25•9 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•9 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•9 years ago
|
Keywords: regression
Comment 27•9 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•9 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!
Reporter | ||
Comment 29•9 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?]
Flags: needinfo?(pbylenga)
Comment 30•9 years ago
|
||
v2.2: https://github.com/mozilla-b2g/gaia/commit/39d854514a57984692c3104c65606fdc253ba520
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Reporter | ||
Comment 31•9 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?]
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.
Description
•