905577 - [Buri]Generic error after USSD expiration

Status: RESOLVED WORKSFORME

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

Description

[sync-1]

Mozilla build ID:20130806071254
 
 DEFECT DESCRIPTION:
 Generic error after USSD expiration
 
  REPRODUCING PROCEDURES:
 1. start USSD session , in VIVO has *204# for USSD
 2. keep active session, how ever with out performing any action
 3. after 2 minutes session must be closed automatically--K.O
 
 phone did not close automatically and displays a generic error
 
  EXPECTED BEHAVIOUR:
 Generic error should NOT be displayed and phone must closed session automatically
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: Logs

Comment 3

[sync-1]

Clone from brother

Comment 4

[sync-1]

Attachment: image

Comment 5

[Viga]

Any response???

Comment 6

[Preeti Raghunath(:Preeti)]

Is this a cert blocker for Buri?

Comment 7

[Viga]

No.

I think it's related to recent refactor in USSD. Gaia receives a onsuccess event,
but the mmiRequest is null.

Comment 8

[Andrew Overholt [:overholt]]

Since this isn't a certification blocker and the user impact doesn't seem too high, we can't block v1.1 on this.

Comment 9

[Fernando Jiménez Moreno [:ferjm]]

Works for me with b2g18 + gaia v1-train + moz RIL

Comment 10

[Viga]

This bug from comercial RIL.
Fernado, do we have an event coming from RIL which tells gaia Session expired?
or just use {sessionEnded, true}?

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

(In reply to weijia from comment #10)
> This bug from comercial RIL.
> Fernado, do we have an event coming from RIL which tells gaia Session
> expired?
> or just use {sessionEnded, true}?

Gaia checks for the sessionEnded flag. If it is set to true and the message is empty, the "Session expired" message is shown.

Comment 12

[Gabriele Svelto [:gsvelto]]

While triaging old bugs we couldn't establish if this is still a problem or not. I suppose this depends on the RIL sending a message with the |sessionEnded| field set to true when the timeout expires. We're certainly not doing anything to handle this in the dialer. Hsin-Yi do you know what's the default RIL behavior in this scenario? Do we get a timeout as suggested in comment 0 expected behavior?

Comment 13

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

(In reply to Gabriele Svelto [:gsvelto] from comment #12)
> While triaging old bugs we couldn't establish if this is still a problem or
> not. I suppose this depends on the RIL sending a message with the
> |sessionEnded| field set to true when the timeout expires. We're certainly
> not doing anything to handle this in the dialer. Hsin-Yi do you know what's
> the default RIL behavior in this scenario? Do we get a timeout as suggested
> in comment 0 expected behavior?

Hi Gabriele,
No, gecko doesn't get information specific to "timeout." What gecko receives is that session is terminated without an idea of the specific reason.

Below are the types of code gecko receives. The USSD session is assumed to persist if the type code is "1", otherwise the current session (if any) is assumed to have terminated.

"0"   USSD-Notify 
"1"   USSD-Request 
"2"   Session terminated by network
"3"   other local client (eg, SIM Toolkit) has responded
"4"   Operation not supported
"5"   Network timeout

F.Y.I, following comment 0, I got "code 2" when I idled for a while. I also got "code 2" when I tried to send a USSD the carrier doesn't support. In my experience, I haven't seen code 3 ~ 5 so far.

Comment 14

[Gabriele Svelto [:gsvelto]]

Thank you for clarifying this Hsin-Yi. Just an additional question, did you get the same behavior as shown in the screenshot (attachment 790702 [details]) when receiving the "code 2" message after waiting for a while?

Comment 15

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

(In reply to Gabriele Svelto [:gsvelto] from comment #14)
> Thank you for clarifying this Hsin-Yi. Just an additional question, did you
> get the same behavior as shown in the screenshot (attachment 790702 [details]
> [details]) when receiving the "code 2" message after waiting for a while?

No, I got "session expired" instead.

Comment 16

[Gabriele Svelto [:gsvelto]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #15)
> No, I got "session expired" instead.

Excellent, then I'll leave it as WORKSFORME since I think this is the behavior expected by comment 0. Thanks for your help