1077392 - The USSD interface shows "Session expired" when is sent a wrong USSD code.

Status: RESOLVED FIXED

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

Description

[Juanjo Iglesias]

The USSD interface shows "Session expired" when is sent a wrong USSD code.

The user should know that he used a bad code.

Steps to reproduce:
1. Insert one SIM card to device
2. Start device and Launch Dialer
3. Enter an USSD string known to be invalid (for example  *123456789#) and send it.
4. The USSD interface is launched and return a message. 

ATUAL:
The USSD interface shows this message: "Session expired"
EXPECTED:
The USSD interface should show a error message.

TESTED:
- Flame 2.0 (Gecko 6349daf , Gaia fa79785) 
- Flame 2.1 (Gecko 74fd606 , Gaia 49f7b3f)

Comment 1

[Johan Lorenzo [:jlorenzo]]

As per comment 0.

Comment 2

[Beatriz Rodríguez [:brg]]

[Blocking Requested - why for this release]:
This issue is affecting the USSD behaviour. When you tried to send a USSD and expect a suitable answer(i.e. with your credit balance), you will only see: "Session expired".

This is a broken feature.

Comment 3

[Johan Lorenzo [:jlorenzo]]

(In reply to Beatriz Rodríguez [:brg] from comment #2)
> When you tried to send a USSD and expect a suitable answer(i.e. with your
> credit balance), you will only see: "Session expired".

I don't think this bug is about the standard path where you want to get information like your credit balance. From the step 3, I understand that you see "Session expired" if you put an invalid USSD. 

In other words, as it's an edge case, I don't think we should block 2.0 on that. What do you think Beatriz?

Comment 4

[Beatriz Rodríguez [:brg]]

(In reply to Johan Lorenzo [:jlorenzo] from comment #3)
> (In reply to Beatriz Rodríguez [:brg] from comment #2)
> > When you tried to send a USSD and expect a suitable answer(i.e. with your
> > credit balance), you will only see: "Session expired".
> 
> I don't think this bug is about the standard path where you want to get
> information like your credit balance. From the step 3, I understand that you
> see "Session expired" if you put an invalid USSD. 
> 
> In other words, as it's an edge case, I don't think we should block 2.0 on
> that. What do you think Beatriz?

Lets use this bug to track the issue when the user type a wrong USSD value.
The expected behaviour is shown the response: Unknown service (or something similar).
This is a certification blocker. USSD must work fine as they are used by some payment services.
version 1.3 is working as expected.

Comment 5

[Johan Lorenzo [:jlorenzo]]

QA wanted for a branch check. As it's a 2.0 issue, please check 1.4 on v123 base image, and if you can reproduce, check on 1.3.

Comment 6

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 1.4 and Flame 1.3 using shallow flash.
Actual result: After entering "*123456789#" in the dialer, the user will see "Session expired" instead of an error message.

Flame 1.4
BuildID: 20141002180522
Gaia: b06fee13c1d80bd2a463be1f2fb1d59169af9298
Gecko: ea144d59c01e
Platform Version: 30.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Flame 1.3
BuildID: 20140627162151
Gaia: 5c43d012a9351e8aaeacda0b87b0886b7f67d33d
Gecko: 
Platform Version: 28.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Comment 7

[Johan Lorenzo [:jlorenzo]]

As per comment 6, the issue does reproduce on the Flame device on 1.3. Did you check 1.3 on this device? If so, can you provide us which commits you had?

Comment 8

[Beatriz Rodríguez [:brg]]

(In reply to Johan Lorenzo [:jlorenzo] from comment #7)
> As per comment 6, the issue does reproduce on the Flame device on 1.3. Did
> you check 1.3 on this device? If so, can you provide us which commits you
> had?

You are right! I can see same behaviour in 1.3 (flame and unagi). Sorry for my mistake and all the inconvenience.
I will remove 2.0 nomination and add it to backlog to improve the response to the user in this case.

Comment 9

[Gabriele Svelto [:gsvelto]]

I've figured out what's happening here. After sending the MMI code we get a response that tells us that sending the code was successful (which is strange) with a status code set to 'scUssd' and an |statusMessage| field. The |mm_notifySuccess()| call bails out here because of that:

https://github.com/mozilla-b2g/gaia/blob/82d2f18154a29c306c6458bac38af8d0b471db1a/apps/communications/dialer/js/mmi.js#L180

The following |mm_handleMMIReceived()| invocation sends the message to the UI with an empty |message| field, here:

https://github.com/mozilla-b2g/gaia/blob/82d2f18154a29c306c6458bac38af8d0b471db1a/apps/communications/dialer/js/mmi.js#L340

The UI looks at that field and since it doesn't have a message to show uses the session expired message:

https://github.com/mozilla-b2g/gaia/blob/ce8144588fa701b6ee96bf3120110d135c40e036/apps/communications/dialer/js/mmi_ui.js#L179

I'm not sure what the expected behavior would be here though for two reasons:

- I don't think we have UX for this specific scenario.

- Maybe we don't need some new UX, but the RIL should send us a message with a meaningful description (e.g. wrong MMI code or something). If this is the case though I wouldn't know what kind of message we would expect nor what do we get from the carrier.

Hsin-Yi, sorry to bother you for the 100th time this week but do you happen to know what kind of message should be delivered to gaia in this scenario? Right now the result field of the success handler looks like this:

evt.target.result = {
  serviceCode: 'scUssd',
  statusMessage: '',
  success: true
}

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Gabriele Svelto [:gsvelto] from comment #9)
> 
> Hsin-Yi, sorry to bother you for the 100th time this week but do you happen
> to know what kind of message should be delivered to gaia in this scenario?
> Right now the result field of the success handler looks like this:
> 

Please don't say so. We are the team working together to make FxOS better, Gabriele :)

Sorry that I haven't got a chance to investigate this today. I'll take a look at this Monday. Keep NI on me for tracking!

> evt.target.result = {
>   serviceCode: 'scUssd',
>   statusMessage: '',
>   success: true
> }

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Gabriele Svelto [:gsvelto] from comment #9)
> I've figured out what's happening here. After sending the MMI code we get a
> response that tells us that sending the code was successful (which is
> strange) with a status code set to 'scUssd' and an |statusMessage| field.
> The |mm_notifySuccess()| call bails out here because of that:
> 
> https://github.com/mozilla-b2g/gaia/blob/
> 82d2f18154a29c306c6458bac38af8d0b471db1a/apps/communications/dialer/js/mmi.
> js#L180
> 
> The following |mm_handleMMIReceived()| invocation sends the message to the
> UI with an empty |message| field, here:
> 
> https://github.com/mozilla-b2g/gaia/blob/
> 82d2f18154a29c306c6458bac38af8d0b471db1a/apps/communications/dialer/js/mmi.
> js#L340
> 
> The UI looks at that field and since it doesn't have a message to show uses
> the session expired message:
> 
> https://github.com/mozilla-b2g/gaia/blob/
> ce8144588fa701b6ee96bf3120110d135c40e036/apps/communications/dialer/js/
> mmi_ui.js#L179
> 
> I'm not sure what the expected behavior would be here though for two reasons:
> 
> - I don't think we have UX for this specific scenario.
> 
> - Maybe we don't need some new UX, but the RIL should send us a message with
> a meaningful description (e.g. wrong MMI code or something). If this is the
> case though I wouldn't know what kind of message we would expect nor what do
> we get from the carrier.
> 
> Hsin-Yi, sorry to bother you for the 100th time this week but do you happen
> to know what kind of message should be delivered to gaia in this scenario?
> Right now the result field of the success handler looks like this:
> 
> evt.target.result = {
>   serviceCode: 'scUssd',
>   statusMessage: '',
>   success: true
> }

Hi Gabriele,
In the case of 'scUssd'  there is no 'statusMessage' coming along with the request success event. The status or the reply (if there's any) from carrier will come later with the upcoming 'ussdreceived' event, per http://androidxref.com/4.4.4_r1/xref/hardware/ril/include/telephony/ril.h#1774

The right solution is to simply remove the whole 'scUssd' case handling below, 
https://github.com/mozilla-b2g/gaia/blame/82d2f18154a29c306c6458bac38af8d0b471db1a/apps/communications/dialer/js/mmi.js#L176

Comment 12

[Gabriele Svelto [:gsvelto]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #11)
> The right solution is to simply remove the whole 'scUssd' case handling
> below, 
> https://github.com/mozilla-b2g/gaia/blame/
> 82d2f18154a29c306c6458bac38af8d0b471db1a/apps/communications/dialer/js/mmi.
> js#L176

Great, thanks! I'll add that to the unit-tests too.

Comment 13

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Do not show a session expiration message when receiving an empty USSD event

This turned out to be one of the silliest bugs ever. We showed the session expiration message because we explicitly checked for the ussdevent message field to be null instead of just empty. It's a one-line fix but I've added a couple of unit-tests to cover this particular scenario.

Comment 14

[Gabriele Svelto [:gsvelto]]

Attachment: [PULL REQUEST] Do not show a session expiration message when receiving an empty USSD event

Comment 17

[Gabriele Svelto [:gsvelto]]

Thanks for the review, try is green: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=766411fe5cc9

Pushed to gaia/master a33dc866dd0661616587cab531418d5afa997133