Closed
Bug 857515
Opened 12 years ago
Closed 12 years ago
[Buri][Shira-48160][USSD]The USSD notification should not be allowed reply
Categories
(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)
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:
Comment 1•12 years ago
|
||
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?
Comment 2•12 years ago
|
||
tef- until we address comment 1
blocking-b2g: tef? → -
Flags: needinfo?(sync-1)
Comment 4•12 years ago
|
||
Then I suggest the call is made by Mozilla directly
Flags: needinfo?(akeybl)
Comment 5•12 years ago
|
||
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.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Updated•6 years ago
|
Flags: needinfo?(akeybl)
You need to log in
before you can comment on or make changes to this bug.
Description
•