1118701 - [FFOS2.0][Woodduck][STK]There has no indication given to the user during the REFRESH

Status: RESOLVED INVALID

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

Description

[sync-1]

DEFECT DESCRIPTION:[STK]There has no indication  given to the user during the REFRESH 
 
  REPRODUCING PROCEDURES:
 1. Load a simcard to the phone which can send "refresh".
 2. Executed "refresh-STM07002",during command refresh executed, there has no indication  given to the user.--ko
 
  EXPECTED BEHAVIOUR:
 2. Executed "refresh-STM07002",during command refresh executed, there should have indication  given to the user.
 
 Reporter's phone number: 0752-2639695
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Josh Cheng [:josh]]

Hi Sean,
Could you please help to check the problem? Thanks!

Comment 2

[Sean Lee [:seanlee][:weilonge]]

Attachment: Trail Patch for v2.0m

Hi Pengfei,

This patch provides a feature that a notification will be shown when a refresh command is received.

Thanks.

Comment 3

[pengfei.huang]

Hi Sean lee,
  Your patch works well. But after refreshing, the notification still exist.
  Besides there is a big question about operator pushing message. VAL confirm different operators may push various message to phone which including some message(refresh command will executed) shouldn't inform user. And we couldn't confirm what exactly type of refresh operator will push. So, user may receive notifications suddenly.
  I will check android code to see how they implements this feature.Thanks

Comment 4

[Sean Lee [:seanlee][:weilonge]]

Hi Pengfei,

In my patch at comment 2, this is a sample patch for you.
The notification will be closed if the card state is changed to 'ready' .
If the condition of notification closed is confirmed, the design can be improved then.

Comment 5

[pengfei.huang]

(In reply to Sean Lee [:seanlee] from comment #4)
> Hi Pengfei,
> 
> In my patch at comment 2, this is a sample patch for you.
> The notification will be closed if the card state is changed to 'ready' .
> If the condition of notification closed is confirmed, the design can be
> improved then.

  Yes, I try your patch on comment3. We receive the notification but it isn't remove after a while when refresh command executed. I add some DUMP log and will try again tonight.
    
+    DUMP('command.commandQualifier:' + message.command.commandQualifier);
     if (message.command.commandQualifier === 0x04) {
       createResetNotification();
       if (!this.stkResetHandler) {
         this.stkResetHandler = function() {
           var iccManager = window.navigator.mozIccManager;
           var iccCard = iccManager.getIccById(message.iccId);
           var cardState = iccCard.cardState;
+          DUMP('cardState:' + cardState);
           if (cardState === 'ready') {
             resetNotification.close();
           }
         };


  I ask android developer and they confirm there is no any code to show the refresh icon at application layer but it exists on android. So, android developer guess it's Android OS implements that but they don't know the detail too.

Comment 6

[Sean Lee [:seanlee][:weilonge]]

In my sample code (this is not a final design, just a sample.),
the notification will be closed when the two case happened:
1. User closes it manually.
2. The card state is changed to 'ready' .

Could you help to confirm whether 'cardstatechange' event is triggered?

If it is not triggered, the notification not closed automatically is expected.

Comment 7

[pengfei.huang]

(In reply to Sean Lee [:seanlee] from comment #6)
> In my sample code (this is not a final design, just a sample.),
> the notification will be closed when the two case happened:
> 1. User closes it manually.
> 2. The card state is changed to 'ready' .
> 
> Could you help to confirm whether 'cardstatechange' event is triggered?
> 
> If it is not triggered, the notification not closed automatically is
> expected.

  The event not triggered.

Comment 8

[pengfei.huang]

Hi Sean,
  VAL can't find another good idea for us to implements so that we can ignore this bug.
  Many thanks.

Comment 9

[Sean Lee [:seanlee][:weilonge]]

Per comment 8, this issue can be closed.

Comment 10

[sync-1]

Dear Wayne Teng,
   we can close this bug, please see TCL bug862838.
   Thanks