861754 - [Buri][Shira-48161][USSD]Terminal behavior when more then one USSD message was sent to terminal

Status: RESOLVED WONTFIX

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

Description

[sync-1]

+++ This bug was initially created as a clone of Bug #434691 +++
 
 Description: 
 When you send to tereminal more than one ussd message, only last message is visible. It's not able to rear last messages
 
 
 Customer Impact Statement: 
 
 
 
 Expected Behaviour:
 All received messages should be visible 
 
 
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #434691 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Fernando Jiménez Moreno [:ferjm]]

Could you test this again with the patches from bug 853798, please?

Comment 2

[Daniel Coloma:dcoloma]

As Fernando has said, changes in USSD has just landed to fix another bug, could you please re-test and nominate again if still occurs?

Comment 3

[Viga]

OK I'll re-test when the code synced.

Comment 4

[Viga]

I see patch related to bug 856534 has been landed on master.
But, our code based on v1.0.1 branch. Can you give a push on uplifting the change on v1.0.1?

Comment 5

[Viga]

It still appears with the patch uplifted to v1.0.1

Comment 6

[Daniel Coloma:dcoloma]

Fernando, can you check what's up?

Comment 7

[Fernando Jiménez Moreno [:ferjm]]

We don't save a stack of received messages in the USSD UI, that's why only the last one is shown (which is supposed to be the valid one).

I can't think about any reason for not doing it that way. I mean, for example, in this scenario:

1. Send an USSD request.
2. Receive an USSD response like "Request accepted".
3. Receive an USSD response with the result of the USSD request, a few ms after the previous one.
4. Only the last one is visible because 3. arrives while the UI is being opened.

Can you explain an scenario where we need to show the full stack of received USSD messages? What would be the UX in that case? Note that we are closing the USSD session when we close the USSD UI via the 'X' button.

We might receive USSD messages from different USSD sessions, but AFAIK we don't have a way to differentiate between sessions.

Do we know what is the behavior in other platforms?

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

not sure if you can respond to comment 7? weijia
Thanks 

(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo instead of CC, please) from comment #7)
> We don't save a stack of received messages in the USSD UI, that's why only
> the last one is shown (which is supposed to be the valid one).
> 
> I can't think about any reason for not doing it that way. I mean, for
> example, in this scenario:
> 
> 1. Send an USSD request.
> 2. Receive an USSD response like "Request accepted".
> 3. Receive an USSD response with the result of the USSD request, a few ms
> after the previous one.
> 4. Only the last one is visible because 3. arrives while the UI is being
> opened.
> 
> Can you explain an scenario where we need to show the full stack of received
> USSD messages? What would be the UX in that case? Note that we are closing
> the USSD session when we close the USSD UI via the 'X' button.
> 
> We might receive USSD messages from different USSD sessions, but AFAIK we
> don't have a way to differentiate between sessions.
> 
> Do we know what is the behavior in other platforms?

Comment 10

[Viga]

Android Samsung is as described. It receives all the notifications one by one after user press OK button to close the latest one.
I think it's an unsolicited message. And don't even need to store the ussd session. It should looks like a MMI check. Don't need to reply to operator. And don't even need to show a reply box.(Mozilla Bug 866743 track this problem)

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

We can do that, but I am afraid that it might require some changes in the platform to add a session/window identifier. We are not opening a new window for each USSD/MMI session, so we need to keep a fake stack of USSD/MMI windows and we need a way to identify each window. The only way I can think about is assigning an ID to each USSD/MMI request.

Anthony, what do you think?

Comment 12

[Viga]

some one take this bug?

Comment 13

[Anthony Ricaud (:rik)]

Fernando: I'm not sure we need a session parameter. We could store all incoming MMI messages and wait till the user press OK/Cancel to display the next one. I guess we can do that either in Gecko with an API change or in Gaia.

But I'd like to see what Android does in this case:
1 - User: Start a MMI session
2 - Operator: Responds to this session
3 - Operator: Sends an unrelated MMI message
4 - User: Sends a response to the first user-initiated session
5 - Should we wait for the answer to the message in 4 or display the message received in 3?

In any case, this is a feature request and we're focused on other priorities right now.

Comment 14

[Amelie Kong]

Answer of the question:
2. Receive an USSD response like "Request accepted"., what does it mean?

If in some way you close a message (affirming) that is not the point. 

The scenario should appear as follows: 
1 Send a USSD a message to the terminal and do not do anything 
2 Send another message 
3 After confirming the last visible messages should be displayed first received
message

About behavior in other platforms, se in Android 4+ (For example Samsung i9100
galaxy SII)

Comment 15

[Alex Keybl [:akeybl]]

Amelie - this is a new feature request (see comment 13), so it is not clear why this would block v1.1 but not v1.0.1.

Comment 16

[Viga]

I think it's critical that user could miss some important USSD messages.
And it still exists on v1.1 
No matter it's a block or request, we just want to get it fixed ASAP.

Comment 17

[Wayne Chang [:wchang]]

Triage - leo- as feature request and not required for 1.1

Comment 18

[Viga]

As I described, user may miss some USSD messages. It's a kind of feature incomplete.
And we think that it's a blocker.

Comment 19

[Viga]

Someone take a look at this bug?

Comment 20

[Joe Cheng [:jcheng] (please needinfo)]

unless this is a blocker for a specific v1.1 release, koi? for now

Comment 21

[Amelie Kong]

Hi, Joe, this is Shira Bug, and was postponed from tef to leo.
We think it is a blocker for Shira side V1.1 release.

Please consider.

Comment 22

[Joe Cheng [:jcheng] (please needinfo)]

Jorge/Wilfred will confirm further

Comment 23

[Joe Cheng [:jcheng] (please needinfo)]

ni? Wilfred

Comment 24

[Joe Cheng [:jcheng] (please needinfo)]

add to backlog 891754

Comment 25

[Wilfred Mathanaraj [:WDM]]

given v1.1 approval can we confirm if this is still a needed bug?

Comment 26

[Mingming ZHAO]

Hi, how about this issue now?

Comment 27

[Jack Liu]

It's IOT blocking issue.

Comment 28

[Preeti Raghunath(:Preeti)]

Backlog for now. We will not be blocking 1.3 on this.

Comment 29

[Joe Cheng [:jcheng] (please needinfo)]

hi Jack, can you please provide more information as to why this is a blocker and from which partner? Thanks

Comment 30

[Mingming ZHAO]

As description in comment 16, if the Operator send more than one USSD message to the user, but the phone only display the last one message, the user could miss some important USSD messages. What do you think?

Comment 31

[Anthony Ricaud (:rik)]

We shipped phones with this issue already. So we won't block a release on this. What has changed since 1.1 that makes this bug more serious?

Comment 32

[Jack Liu]

(In reply to Joe Cheng [:jcheng] from comment #29)
> hi Jack, can you please provide more information as to why this is a blocker
> and from which partner? Thanks

Hi Joe, Shira is code of DT.

Comment 33

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

This issue is waived in v1.0.1 for DT IOT. According to the Blocker Triage Guideline(https://wiki.mozilla.org/B2G/Triage#Issues_that_Should_Block), we should nominate Certification waivers from the previous release as blocker

ni Jason for further comments

Comment 34

[Jason Smith [:jsmith]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #33)
> This issue is waived in v1.0.1 for DT IOT. According to the Blocker Triage
> Guideline(https://wiki.mozilla.org/B2G/Triage#Issues_that_Should_Block), we
> should nominate Certification waivers from the previous release as blocker
> 
> ni Jason for further comments

That's true, but if it's a feature request, we need to know this immediately that we need to resolve this in the next version while the next version is early in the release cycle. Otherwise, we'll run into trouble trying to get this into the next version, as it will be too risky to land it in the next version if the next version is late in the release cycle. In this bug's case, it's quite risky to land this feature at this time in 1.3, as we're at the end of the release cycle right now.

I'm switching the needinfo to Wilfred here, as he can make a product call here on what we should do in 1.3 & what we should do in future releases here.

Comment 35

[Mingming ZHAO]

Hi, how about this issue now?

Comment 36

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Mingming ZHAO from comment #35)
> Hi, how about this issue now?

Hi Mingming -

We are discussing about this issue with DT as well, but for now, I believe this issue will not be implemented in 1.3

Thanks

Vance

Comment 37

[Peter Dolanjski [:pdol]]

Commenting on Wilfred's behalf while he is out:
I think the backlog decision is the right one here.  I'll leave Wilfred on NI to add this as a top fix backlog issue.

Comment 38

[Wilfred Mathanaraj [:WDM]]

As discussed with DT this is not blocking v1.3 - not all issues that was waived during v1.0.1/v1.1 testing is blocking v1.3 and all future versions.

We agree this is a required feature but we more drastic issues to fix before we get to this item. As such this will be backlogged to to be done when we have some time to do such work.

Perhaps this is the work we need to assign to the top25 for anyone to pickup external contribution on.

Comment 39

[Jack Liu]

[Blocking Requested - why for this release]:

Hi Wesly,

It's a blocking issue since 1.1, please help to fix in 2.0.

Thanks.

Comment 40

[Wesly Huang (EPM)]

Hi Jack:

Per history this is come from FT before, is it still the case now? Given current timing of 2.0 I'm afraid we won't set it as blocker.

Comment 41

[Lingling Zhao]

Dear Wesly,

If the Operator send more than one USSD message to the user, but the device only display the last one message, the user could miss some important USSD messages. So this issue should be fixed.

Comment 42

[Doug Sherk (:drs) (inactive)]

This is a feature request, so on the surface I don't think it makes sense to request blocking for 2.2. We could flag it as |feature-b2g: 2.3?| though, and get to it on our next release.

Comment 43

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

this is a feature

Comment 44

[BMO Automation]

Firefox OS is not being worked on