Closed Bug 857515 Opened 11 years ago Closed 11 years ago

[Buri][Shira-48160][USSD]The USSD notification should not be allowed reply

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:-)

RESOLVED INVALID
blocking-b2g -

People

(Reporter: sync-1, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #433026 +++
 
 AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.044
 Firefox os  v1.0.1
 Mozilla build ID: 20130319070203
 
 Created an attachment (id=379560)
 snapshot
 
 DEFECT DESCRIPTION:
 [USSD]The USSD notification should not be allowed reply
 
 REPRODUCING PROCEDURES:
 1.when you receive the USSD notification 
 2.there is a place to answer to received message. This "place" should not be available. The USSD notification should not have any place to input some text. 
 
 EXPECTED BEHAVIOUR:
 The USSD notification should not have any place to input text.
 
 ASSOCIATE SPECIFICATION:
 TEST PLAN REFERENCE:
 TOOLS AND PLATFORMS USED:
 USER IMPACT:
 REPRODUCING RATE:5/5
 For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #433026 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:
blocking-b2g: --- → tef?
Why not?

If the USSD message does not explicitly indicates that the session is ended we should not forbid a possible reply. Is this the case of an USSD message with an explicit session ended?
tef- until we address comment 1
blocking-b2g: tef? → -
Flags: needinfo?(sync-1)
DT request fix it
Flags: needinfo?(sync-1)
Then I suggest the call is made by Mozilla directly
Flags: needinfo?(akeybl)
I clearly didn't make my point. Sorry for my poor explanation above. Let me put it this way:
Every USSD message received by the RIL, and hence by Gecko, contains a flag indicating whether the USSD session has been closed by the server or not. When we get this flag to *true*, indicating that the carrier application does not expect a reply to its USSD message, *we don't show* any reply field in the UI along with the USSD notification. When we receive this flag as *false*, meaning that the session is kept alive and the carrier application expects a reply from the user, *we show* a field where the user can introduce and send the appropiate reply to the carrier's USSD application so the whole application flow can be completed. The user must also be able to close an active session whenever she decides to. In this case, it can be done just by closing the dialog containing the USSD notification.

If we don't show the reply form within the USSD notification *in any case*, as it seems that this bug report is requesting, we will be breaking a very basic USSD functionality, which are what are usually called interactive USSD applications.

So, unless there is a clear proof (an adb logcat with RIL debug information would work) that we are showing the reply form when we receive an USSD message with a 'sessionEnded' set to 'true', IMHO this bug is a WONTFIX. If we are showing the reply form even when the USSD session is closed, then we will need to fix that and I'll be glad to do it myself.
Dear Weijia,
 
 Please help to follow up with mozilla
Please close it. The brother bug has been closed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Flags: needinfo?(akeybl)
You need to log in before you can comment on or make changes to this bug.