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

NEW
Unassigned

Status

Firefox OS
Gaia::Dialer
P2
normal
5 years ago
2 years ago

People

(Reporter: sync-1, Unassigned)

Tracking

(Blocks: 1 bug, {cert-waiver, feature})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Poland, IOT, Buri, [priority])

(Reporter)

Description

5 years ago
+++ 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:

Updated

5 years ago
blocking-b2g: --- → tef?
Could you test this again with the patches from bug 853798, please?
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?
blocking-b2g: tef? → -
Flags: needinfo?(sync-1)

Comment 3

5 years ago
OK I'll re-test when the code synced.
Flags: needinfo?(sync-1)

Comment 4

5 years ago
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

5 years ago
It still appears with the patch uplifted to v1.0.1
Flags: needinfo?(dcoloma)
Fernando, can you check what's up?
Flags: needinfo?(dcoloma)

Updated

5 years ago
Flags: needinfo?(ferjmoreno)
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?
Flags: needinfo?(ferjmoreno)
Duplicate of this bug: 869300

Updated

5 years ago
Blocks: 869681

Updated

5 years ago
Whiteboard: Poland, IOT, Buri
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?
Flags: needinfo?(liweijia)

Comment 10

5 years ago
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)
Flags: needinfo?(liweijia)
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?
Flags: needinfo?(anthony)

Comment 12

5 years ago
some one take this bug?
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.
Flags: needinfo?(anthony)

Comment 14

5 years ago
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)
blocking-b2g: - → leo?
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.
Flags: needinfo?(mei.kong)
Keywords: feature

Comment 16

5 years ago
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.
Flags: needinfo?(mei.kong)
Triage - leo- as feature request and not required for 1.1
blocking-b2g: leo? → ---

Comment 18

5 years ago
As I described, user may miss some USSD messages. It's a kind of feature incomplete.
And we think that it's a blocker.
Flags: needinfo?(wchang)

Updated

5 years ago
Flags: needinfo?(wchang) → needinfo?(jcheng)

Comment 19

5 years ago
Someone take a look at this bug?
unless this is a blocker for a specific v1.1 release, koi? for now
blocking-b2g: --- → koi?
Flags: needinfo?(jcheng)

Comment 21

5 years ago
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.
Whiteboard: Poland, IOT, Buri → Poland, IOT, Buri [comms-triaged]
Jorge/Wilfred will confirm further
ni? Wilfred
Flags: needinfo?(wmathanaraj)
add to backlog 891754
Blocks: 891754
blocking-b2g: koi? → ---
given v1.1 approval can we confirm if this is still a needed bug?
Flags: needinfo?(wmathanaraj)

Comment 26

4 years ago
Hi, how about this issue now?

Comment 27

4 years ago
It's IOT blocking issue.
blocking-b2g: --- → 1.3?
Backlog for now. We will not be blocking 1.3 on this.
blocking-b2g: 1.3? → backlog
hi Jack, can you please provide more information as to why this is a blocker and from which partner? Thanks
Flags: needinfo?(liuyongming)

Comment 30

4 years ago
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?
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

4 years ago
(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.
Flags: needinfo?(liuyongming)
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
Flags: needinfo?(jsmith)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] 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.
Flags: needinfo?(jsmith) → needinfo?(wmathanaraj)

Comment 35

4 years ago
Hi, how about this issue now?
(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
Whiteboard: Poland, IOT, Buri [comms-triaged] → Poland, IOT, Buri, [Top25]
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.
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.
Flags: needinfo?(wmathanaraj)
Whiteboard: Poland, IOT, Buri, [Top25] → Poland, IOT, Buri, [priority]
Keywords: cert-waiver

Comment 39

3 years ago
[Blocking Requested - why for this release]:

Hi Wesly,

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

Thanks.
blocking-b2g: backlog → 2.0?
Flags: needinfo?(wehuang)
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.
Flags: needinfo?(wehuang)

Comment 41

3 years ago
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.
blocking-b2g: 2.0? → 2.2?
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.
this is a feature
blocking-b2g: 2.2? → backlog
Flags: needinfo?(wmathanaraj)
(Assignee)

Updated

3 years ago
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
tracking-b2g: backlog → ---
Flags: needinfo?(wmathanaraj)
Blocks: 1258652
You need to log in before you can comment on or make changes to this bug.