Closed
Bug 993807
Opened 10 years ago
Closed 10 years ago
[OPEN C_1.3] Send ussd fail
Categories
(Firefox OS Graveyard :: Gaia::Dialer, defect)
Tracking
(blocking-b2g:1.3+, 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)
14.38 KB,
application/x-7z-compressed
|
Details | |
14.38 KB,
application/x-7z-compressed
|
Details | |
1.06 MB,
application/x-7z-compressed
|
Details | |
13.58 KB,
application/x-7z-compressed
|
Details | |
1.10 MB,
application/x-7z-compressed
|
Details | |
4.06 MB,
application/x-7z-compressed
|
Details | |
46 bytes,
text/x-github-pull-request
|
rik
:
review+
bajaj
:
approval-gaia-v1.3+
|
Details | Review |
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
(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?
Comment 8•10 years ago
|
||
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+
Comment 9•10 years ago
|
||
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: qawanted → regression
Whiteboard: [cert]
Comment 10•10 years ago
|
||
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.
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Comment 11•10 years ago
|
||
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.
Reporter | ||
Comment 12•10 years ago
|
||
Comment 13•10 years ago
|
||
(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.
Reporter | ||
Comment 14•10 years ago
|
||
(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~
Comment 15•10 years ago
|
||
The fix needs to come from Mozilla.
Assignee | ||
Comment 17•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(anthony)
Comment 18•10 years ago
|
||
(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
Comment 19•10 years ago
|
||
(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.
Updated•10 years ago
|
Assignee: nobody → etienne
Updated•10 years ago
|
Target Milestone: --- → 1.4 S6 (25apr)
Assignee | ||
Comment 20•10 years ago
|
||
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)
Updated•10 years ago
|
Attachment #8405292 -
Flags: review?(anthony) → review+
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Assignee | ||
Comment 21•10 years ago
|
||
https://github.com/mozilla-b2g/gaia/commit/79e2919fb2cb2f1745dae6f7290cec95526c8221
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
status-b2g-v1.3:
--- → affected
Comment 22•10 years ago
|
||
Please request approval-gaia-v1.3 on this when it is ready for uplift to v1.3.
Assignee | ||
Comment 23•10 years ago
|
||
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)
Comment 24•10 years ago
|
||
(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.
Comment 25•10 years ago
|
||
v1.4: https://github.com/mozilla-b2g/gaia/commit/961f7d4d51065cbe02e0546582817cddd4490f85
Already confirmed with partner, the patch is OK and can solve this issue. Please land it on 1.3. Thanks
Flags: needinfo?(bbajaj)
Updated•10 years ago
|
Attachment #8405292 -
Flags: approval-gaia-v1.3? → approval-gaia-v1.3+
Flags: needinfo?(bbajaj)
Comment 27•10 years ago
|
||
v1.3: https://github.com/mozilla-b2g/gaia/commit/5b64e408148f87c398932a683f81ea32323fccb1
Updated•10 years ago
|
status-b2g-v1.3T:
--- → fixed
Updated•10 years ago
|
Flags: in-moztrap?
Updated•10 years ago
|
Flags: in-moztrap? → in-moztrap-
Comment 28•10 years ago
|
||
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.
Description
•