Closed Bug 993807 Opened 7 years ago Closed 7 years ago

[OPEN C_1.3] Send ussd fail

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

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

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

People

(Reporter: fu.chun, Assigned: etienne, NeedInfo)

Details

(Keywords: regression, Whiteboard: [cert])

Attachments

(7 files, 1 obsolete file)

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E; Zune 4.7; TCO_20140409094409; SE 2.X MetaSr 1.0)

Steps to reproduce:

When we receive a ussd command *119# appear in the screen a message of please send something, we introduce a word and the network must reply the same to the phone, when we press send the phone show the message sending and never send and the message sending not disappear of the screen


Actual results:

when we press send the phone show the message sending and never send and the message sending not disappear of the screen


Expected results:

when wen press send the phone can send this message to the network and can receive the message sending by network
blocking-b2g: --- → 1.3?
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Attached file ussd not work qxdm log
Attached file another AP log
Attached file another qxdm log
Severity: normal → critical
(In reply to fu.chun from comment #0)
> Created attachment 8403715 [details]
ussd not works AP log.7z

User Agent:
> Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET
> CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0;
> InfoPath.2; .NET4.0C; .NET4.0E; Zune 4.7; TCO_20140409094409; SE 2.X MetaSr
> 1.0)

Steps to reproduce:

When we receive a ussd command *119# appear in
> the screen a message of please send something, we introduce a word and the
> network must reply the same to the phone, when we press send the phone show
> the message sending and never send and the message sending not disappear of
> the screen


Actual results:

when we press send the phone show the message
> sending and never send and the message sending not disappear of the screen

> Expected results:

when wen press send the phone can send this message to
> the network and can receive the message sending by network



For the log about the ussd *119# we start the log-> receive the code *119# -> write some characters -> the phone show sending and not send
For USSD  codes like *128# , *515# and *987*1257# not works I take logs AP and QXDM, and the name are ussd not works, the log are only for *128# because with the 3 options the answer is the same.
Hi,
  We also raise a SR:01513771 to Qualcomm, and his engineer analysis as following:
 +++++++++++++++++++++++++
From the logs it looks like that the USSD response is being sent as dial request instead of USSD and  so the network will never send the response back for USSD and would explain why UI is stuck in sending screen. Telephony is expecting that in this case Gaia calls SendMMI API but seems like that API might have changed.
 
04-08 16:03:27.207 D/use-Rlog/RLOG-RIL_QC_B2G(  298): [SUB0] [UNSL]< UNSOL_ON_USSD {1,Ingresa Algo}
04-08 16:03:35.757 D/use-Rlog/RLOG-RIL_QC_B2G(  298): [SUB0] [0128]> DIAL 55 0
+++++++++++++++++++++++++

  Why send ussd command as dial command?
Can we check to see if we can reproduce this on 1.3?
Keywords: qawanted
Just to clarify, the STR are:

0) the operator sends a USSD command to the terminal under test 
1) a USSD message arrives to the terminal (in the reporter's case, which happened in Perú, the message arrives as being sent by '*119#'), and asks the user to write something back
2) once the user writes anything and click on "send", the UI shows "sending" forever, and the message never arrives to the server.

This bug was NOT present in Open (with FxOS v1.1) so I believe it should be a regression. 
Please nominate it to 1.3+
Ok - thanks for the clarification. Blocking this for being a cert issue.
Status: UNCONFIRMED → NEW
blocking-b2g: 1.3? → 1.3+
Component: General → Gaia::Dialer
Ever confirmed: true
Keywords: qawantedregression
Whiteboard: [cert]
I am able to reproduce the issue on 1.3 where clicking send from MMI UI popup doesn't call SendMMI Gecko API causing the UI to be stuck in sending state. The root cause of this behavior however seems to be different from the one reported by the partner. In the logs reported by partner I see a dial request instead of SendMMI however looking at the mmi.js and mmi_ui.js I am not sure how that is possible unless someone cancels the MMI popup and then dial a number. May be someone cancelled the MMI UI popup and sent a dial request using the dialer instead of replying through the MMI UI popup. Assuming that is the case, lets focus on why the MMI UI popup not send a MMI request when the send button is clicked.

I added some log messages in the mmi_ui.js and I see that function mui_reply at http://lxr.mozilla.org/gaia/source/apps/communications/dialer/js/mmi_ui.js#140 does get called when user enters some text in the mmi_ui and hits send but http://lxr.mozilla.org/gaia/source/apps/communications/dialer/js/mmi.js#318 that sends the MMI doesn't get called. Infact even the mmi-cancel event is not getting fired when user click the cancel button.

Will add more analysis as and when I find it.
Did more investigation and it seems like the issue only happens when mmi_ui shows up in response to network initiated USSD. If the user initiates the USSD session then everything is good.
(In reply to fu.chun from comment #12)
> Created attachment 8404389 [details]
> new log that also no dial requrest
Looking at the new logs at least the behavior seems consistent with what I am seeing. This seems like a Gaia issue at this point.
(In reply to Anshul from comment #13)
> (In reply to fu.chun from comment #12)
> Created attachment 8404389 [details]
> [details]
> new log that also no dial requrest
Looking at the new logs at
> least the behavior seems consistent with what I am seeing. This seems like a
> Gaia issue at this point.

Could you please help us to fix it ASAP?
Thanks~
The fix needs to come from Mozilla.
Ni? etienne/Rik
Flags: needinfo?(etienne)
Flags: needinfo?(anthony)
Attached patch Patch proposal (obsolete) — Splinter Review
Thanks Anshul your analysis helps a lot.

Kind of a shot in the dark since I can't test the STR (don't know how to make my provider initiate a MMI session without sending one), but maybe somebody can try this patch and see if it helps?
Flags: needinfo?(etienne) → needinfo?(fu.chun)
Flags: needinfo?(anthony)
(In reply to Etienne Segonzac (:etienne) from comment #17)
> Created attachment 8404608 [details] [diff] [review]
> Patch proposal
> 
> Thanks Anshul your analysis helps a lot.
> 
> Kind of a shot in the dark since I can't test the STR (don't know how to
> make my provider initiate a MMI session without sending one), but maybe
> somebody can try this patch and see if it helps?

Thanks Etienne, I have ask my colleagues to prepare an urgent build with the patch integrated so that we can test it later in Perú, and therefore confirm that the patch is working.

I will let you know ASAP if it really works
(In reply to Etienne Segonzac (:etienne) from comment #17)
> Created attachment 8404608 [details] [diff] [review]
> Patch proposal
> 
> Thanks Anshul your analysis helps a lot.
> 
> Kind of a shot in the dark since I can't test the STR (don't know how to
> make my provider initiate a MMI session without sending one), but maybe
> somebody can try this patch and see if it helps?
I tested your patch and it does seem to solve the issue :). Thanks for the quick turn around. However the way I reproduce the issue was hacking my code so I would wait for a proper test done on the build by juanpbf.
Assignee: nobody → etienne
Target Milestone: --- → 1.4 S6 (25apr)
Attached file Gaia PR
We'll wait for the confirmation of the fix before landing.
But this is ready for review.
Attachment #8404608 - Attachment is obsolete: true
Attachment #8405292 - Flags: review?(anthony)
Attachment #8405292 - Flags: review?(anthony) → review+
https://github.com/mozilla-b2g/gaia/commit/79e2919fb2cb2f1745dae6f7290cec95526c8221
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Please request approval-gaia-v1.3 on this when it is ready for uplift to v1.3.
Flags: needinfo?(etienne)
Comment on attachment 8405292 [details] [review]
Gaia PR

[Approval Request Comment]
[User impact] if declined: fairly small, but this is making a certification automated test fail.

[Testing completed]: tested the classic scenarios of USSD session with multiple message/responses.

[Risk to taking this patch] (and alternatives if risky): small

[String changes made]: none
Attachment #8405292 - Flags: approval-gaia-v1.3?
Flags: needinfo?(etienne)
(In reply to Juan Perez-Bedmar [:juanpbf] from comment #18)
> (In reply to Etienne Segonzac (:etienne) from comment #17)
> > Created attachment 8404608 [details] [diff] [review]
> > Patch proposal
> > 
> > Thanks Anshul your analysis helps a lot.
> > 
> > Kind of a shot in the dark since I can't test the STR (don't know how to
> > make my provider initiate a MMI session without sending one), but maybe
> > somebody can try this patch and see if it helps?
> 
> Thanks Etienne, I have ask my colleagues to prepare an urgent build with the
> patch integrated so that we can test it later in Perú, and therefore confirm
> that the patch is working.
> 
> I will let you know ASAP if it really works

Hey juan, a quick check on if you were able to verify this patch yet or have an eta ? Holding off on getting it landed on 1.3 based on your sign-off.
Already confirmed with partner, the patch is OK and can solve this issue. Please land it on 1.3.

Thanks
Flags: needinfo?(bbajaj)
Attachment #8405292 - Flags: approval-gaia-v1.3? → approval-gaia-v1.3+
Flags: needinfo?(bbajaj)
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap-
Test case can be found here: https://moztrap.mozilla.org/manage/case/13733/
Flags: in-moztrap- → in-moztrap+
You need to log in before you can comment on or make changes to this bug.