1119573 - [FFOS2.0][Woodduck][STK]Message displayed not ok when execute "display text with wait user to clear".

Status: RESOLVED INVALID

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

Description

[sync-1]

DEFECT DESCRIPTION:[STK]Message displayed not ok when execute "display text with wait user to clear".
 
 
  REPRODUCING PROCEDURES:
 1. Load a simcard to the phone which can send "display text";
 2. Execute "Display Text->STM01002->CQ=00 DCS=00",with clearAfterDelay mode, the message will disappeared in one status's time;
 3. Execute "Display Text->STM01002->CQ=80 DCS=00",with userToClearmode, the message will disappeared in one status's time;--ko
 
 
  EXPECTED BEHAVIOUR:
 3. Execute "Display Text->STM01002->CQ=80 DCS=00",with userToClearmode, the message should disappeared in 2 status's time because of userToClearmode mode.
 
 Reporter's 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

[pengfei.huang]

Dear all,
  The detail at TS11.14 12.6:
    Command Qualifier:
      DISPLAY TEXT,
      bit 1:
      0 = normal priority
      1 = high priority
      bits 2-7: = RFU
      bit 8:
      0 = clear message after a delay
      1 = wait for user to clear message
   Maybe we can parse the bit8 of commandQualifier to control the timeout of DISPLAY TEXT.

Comment 2

[pengfei.huang]

Attachment: mtklog displays_1_9.zip

Comment 3

[Josh Cheng [:josh]]

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

Comment 4

[pengfei.huang]

Hi Sean,
  I modify the code and pass the test. Is it right?

  @@ -273,6 +305,9 @@ var icc_worker = {
       timeout = icc.calculateDurationInMS(duration.timeUnit,
         duration.timeInterval);
     }
+    if (options.userClear) {
+      timeout = 2 * timeout;
+    };
 
     if (options.responseNeeded) {
       icc.responseSTKCommand(message, {

Comment 5

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

Hi Pengfei,

IMHO, I think the dialog must be closed by user if options.userClear is TRUE.
We can say setTimeout (in icc.js @ function confirm ) should be disabled by assigning timeout = null .

Here is my suggestion:
In icc_worker.js
  @@ -273,6 +305,9 @@ var icc_worker = {
       timeout = icc.calculateDurationInMS(duration.timeUnit,
         duration.timeInterval);
     }
+    if (options.userClear) {
+      timeout = null;
+    };
 
     if (options.responseNeeded) {
       icc.responseSTKCommand(message, {

Please help to try the patch if it works.
Thank you.

Comment 6

[pengfei.huang]

Hi Sean,
  I take your advice. In the lab test, the DISPLAY TEXT dialog hasn't disappear until user do some operation. VAL co-worker(Liyan.yi) think it's not good for their test standard.

Comment 7

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

Hi Pengfei,

In your patch, timeout = 2 * timeout;
this is just increasing the timeout value but not a exact value.
Could you consult your VAL team to provide a more clear criteria for this case?

Comment 8

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

Could you help to explain why 2 times timeout? Thank you.

Comment 9

[pengfei.huang]

(In reply to Sean Lee [:seanlee] from comment #8)
> Could you help to explain why 2 times timeout? Thank you.
  Our VAL suggest the timeout of "UserClear" should be longer than timeout of "clearAfterDelay" and no exactly time we need to follow. A rule we need to obey is the dialog must be remove when the userClear=true. And there is case "No Response" which userClear=true and dialog must be remove.
  They suggest 2 or 3 times timeout is OK.

Comment 10

[sync-1]

Hi Sean Lee,
   I check android code about the exactly time they use. As follow,
 
     // Display Text timeouts
     static final int DISP_TEXT_CLEAR_AFTER_DELAY_TIMEOUT = (15 * 1000);
     static final int DISP_TEXT_WAIT_FOR_USER_TIMEOUT = (60 * 1000);
 
   so, what exactly time Mozilla will use for best design?

Comment 11

[Josh Cheng [:josh]]

Hi Reporter,
Since comment 9 and comment 10 are only suggestion. If this is is not blocker. I suggest we focus on other issues block certification Thanks!

Comment 12

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

clear ni first since comment 11.

Comment 13

[Josh Cheng [:josh]]

Hi PengFei,
Do you still need our help about this issue?
Thanks!

Comment 14

[pengfei.huang]

Hi Josh,
  Sean had provided solution and I can follow his solution to fix this bug with VAL suggestion. we can close it.
  Thank you!

Comment 15

[pengfei.huang]

Dear Josh,
  And please focus on other issues block GCF certification! They drive me crazy.T_T
  Many thanks.

Comment 16

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

Hi Pengfei,

I think this issue can be resolved by configuring settings without adding any patch (ex comment 4), just like bug 1122326 .
Could you help to check it?

Thank you.

Comment 17

[pengfei.huang]

Hi Sean,
  There is not key and value for timeout of "UserClear" in common-settings.json. We need to add one. What name will you give?

Comment 18

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

Can't we just use icc.displayTextTimeout (which already exists) for UserClear case ?

Comment 19

[pengfei.huang]

(In reply to Sean Lee [:seanlee] from comment #18)
> Can't we just use icc.displayTextTimeout (which already exists) for
> UserClear case ?
  I guess we can't because VAL will oppose us with the wrong timeout which is longer than they expected. we modified the time "icc.displayTextTimeout" to 120000 for bug 1122326 but VAL expected about 40000.

Comment 20

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

Attachment: Trail Patch for v2.0m

Hi Pengfei,

I add icc.userClearTimeout setting for STK_CMD_DISPLAY_TEXT, and its default value is 120000.
Could you help to try the patch?
Thank you!

Comment 21

[pengfei.huang]

Hi Sean,
  Your patch works well and pass the test. 
  I modify the default value to 40000 for VAL special require. Please know it.
  Thanks, Sean.

Comment 22

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

Based on comment 21, this is a special requirement for VAL, so I close the bug.

Comment 23

[sync-1]

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