All users were logged out of Bugzilla on October 13th, 2018

STK: No Terminal Response sent after PLAY_TONE

VERIFIED FIXED

Status

VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: cyang, Assigned: frsela)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
I think there may have been a regression with this one. After an STK proactive command for PLAY_TONE comes, it used to be the case that a Terminal Response was sent after the tone has been played. However, now, after a tone is played, a TR is never sent unless one of the three buttons (Close, Back, Ok) is pressed.

The button presses should still generate the corresponding TRs, but in addition, the TR should be sent automatically once the tone has been played.

According to TS 11.14, Section 6.4.5:

"The ME shall send the TERMINAL RESPONSE (Command performed successfully) as soon as possible after the tone has been completed..."

Sample PDU to test with: D01981030120008202810385073C41424F52543E8E010684020001
Certification blocker and a regression, we'll have to block on this.
Assignee: nobody → frsela
blocking-b2g: tef? → tef+
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
Keywords: qawanted, regression, regressionwindow-wanted
Hi Carol,

In order to clarify:

You mean that after some period without user response the dialog should be closed and responded?

or

STK shall response one message and then another one when the user pushes one of the buttons?

In the second case, which message is needed?

Thanks.
Flags: needinfo?(cyang)
Only need regressionwindow-wanted in this case.
Keywords: qawanted
(Reporter)

Comment 4

6 years ago
(In reply to Fernando R. Sela [:frsela] from comment #2)
> Hi Carol,
> 
> In order to clarify:
> 
> You mean that after some period without user response the dialog should be
> closed and responded?

From what I can tell, it seems like the TR should be sent after the duration of the PLAY_TONE. For example, if the duration is 1 minute, the tone is played for 1 minute and then once it stops playing, the TR is sent immediately after that. Assuming that the tone was played successfully, STK_RESULT_OK would be sent. Otherwise, whatever corresponding result value should be sent.

On this note, if any of the buttons (Close, Back, OK) were pressed before the entire duration time was up, the tone would stop playing and the TR should be sent corresponding to the button press and the dialog would be dismissed (with the Back button taking user to the top of Settings menu), as is the case currently.

> 
> or
> 
> STK shall response one message and then another one when the user pushes one
> of the buttons?

A TR is sent in response to an STK command (whether it's for PLAY_TONE or not). I don't think it makes sense that multiple TR is sent for one STK command. I think there are a couple of options for this:
- 1) Once the TR is sent after the duration of play, then the dialog (with options to press one of the three buttons) should be dismissed
- 2) Once the TR is sent after the duration of play, if the dialog remains but pressing any of the buttons would not issue another TR for the same STK command

> 
> In the second case, which message is needed?

Regardless of how this is fixed, the buttons should still be sending it's corresponding values depending on which button is pressed:
- Close: STK_RESULT_UICC_SESSION_TERM_BY_USER
- Back: STK_RESULT_BACKWARD_MOVE_BY_USER
- Ok: STK_RESULT_OK

> 
> Thanks.

Hope this clears it up. Let me know if you need any other clarification.
Flags: needinfo?(cyang)
I don't think this is a regression, I don't see it implemented if I am looking at this correctly... maybe I'm wrong : https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/icc.js#L207
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 6

6 years ago
(In reply to Naoki Hirata :nhirata from comment #5)
> I don't think this is a regression, I don't see it implemented if I am
> looking at this correctly... maybe I'm wrong :
> https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/icc.js#L207

At some point, I do remember seeing that TR was sent after it was played though. In particular GCF TC 27.22.4.5.1.1 could not proceed to the next step (given user does not press any buttons) since IT3 waits for the TR to come before it issues the next PLAY_TONE.
Created attachment 719867 [details]
Close alert and send response after playtone finish
Attachment #719867 - Flags: review?(21)
Comment on attachment 719867 [details]
Close alert and send response after playtone finish

I made some comments on github. Only small changes.
Attachment #719867 - Flags: review?(21)
Comment on attachment 719867 [details]
Close alert and send response after playtone finish

Debug traces disabled
Attachment #719867 - Flags: review?(21)
Landed: https://github.com/mozilla-b2g/gaia/commit/aafcb4fbcfb303718fdd824ccd7f30e94943c621
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

6 years ago
Hi Fernando,

I've tried manually pulling this onto a v1.0.1 branch of mine to test with and still do not see the TR being sent after tone has been played. I assume that line 827 is what sends the TR here?

https://github.com/mozilla-b2g/gaia/commit/aafcb4fbcfb303718fdd824ccd7f30e94943c621#L0R827

I added some debug around there and never saw it go to that line. Can you please try testing with this PDU (preferably on v1.0.1) and see if you get a TR after the tone plays for 5 seconds?

Dial Tone: D01B81030120008202810385094469616C20546F6E658E010184020105
(Reporter)

Updated

6 years ago
Flags: needinfo?(frsela)
(In reply to Carol Yang from comment #11)
> Hi Fernando,
> 
> I've tried manually pulling this onto a v1.0.1 branch of mine to test with
> and still do not see the TR being sent after tone has been played. I assume
> that line 827 is what sends the TR here?
> 
> https://github.com/mozilla-b2g/gaia/commit/
> aafcb4fbcfb303718fdd824ccd7f30e94943c621#L0R827
> 

Yes, it's the line

> I added some debug around there and never saw it go to that line. Can you
> please try testing with this PDU (preferably on v1.0.1) and see if you get a
> TR after the tone plays for 5 seconds?
> 
> Dial Tone: D01B81030120008202810385094469616C20546F6E658E010184020105

I'll test asap, meanwhile, can you provide the logcat with debug enable to see if the timer registration is ok?
Flags: needinfo?(frsela)

Comment 13

6 years ago
Reopening as Carol thinks that the issue is not yet resolved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 12 seems to indicate that Fernando could use a logcat with debug enabled.  Can that be provided?
Flags: needinfo?(cyang)
(Reporter)

Comment 15

6 years ago
Created attachment 724698 [details]
STKUI debug trace after manual pull in of attachment 719867 [details]

This contains debug logs for the following:

1) Manually pull in attachment 719867 [details]
2) Send a few dial tone STK proactive commands

After duration of play tone, no terminal response is sent and the options for Close/Back/OK is dismissed. In particular, I noticed these log messages after duration of play tone:

GeckoConsole: Content JS LOG at app://settings.gaiamobile.org/js/utils.js:20 in debug: [DEBUG # Settings] sendStkResponse -- # response = {"resultCode":0}
GeckoConsole: Content JS LOG at app://settings.gaiamobile.org/js/utils.js:20 in debug: [DEBUG # Settings] sendStkResponse NO COMMAND TO RESPONSE. Ignoring
Flags: needinfo?(cyang)
Hi,

(In reply to Carol Yang from comment #15)
> Created attachment 724698 [details]
> STKUI debug trace after manual pull in of attachment 719867 [details]
> 
> This contains debug logs for the following:
> 
> 1) Manually pull in attachment 719867 [details]
> 2) Send a few dial tone STK proactive commands
> 
> After duration of play tone, no terminal response is sent and the options
> for Close/Back/OK is dismissed. In particular, I noticed these log messages
> after duration of play tone:
> 

After finish tone, the dialog should be closed and a response should be sent: https://github.com/frsela/gaia/blob/master/apps/settings/js/icc.js#L825

Is this what happens?

> GeckoConsole: Content JS LOG at app://settings.gaiamobile.org/js/utils.js:20
> in debug: [DEBUG # Settings] sendStkResponse -- # response = {"resultCode":0}
> GeckoConsole: Content JS LOG at app://settings.gaiamobile.org/js/utils.js:20
> in debug: [DEBUG # Settings] sendStkResponse NO COMMAND TO RESPONSE. Ignoring

Looking the traces a response with 0 has been sent and then a new try to response had been done but as it had been responded (0) no command to response is displayed.
(Reporter)

Comment 17

6 years ago
(In reply to Fernando R. Sela [:frsela] from comment #16)
> After finish tone, the dialog should be closed and a response should be
> sent: https://github.com/frsela/gaia/blob/master/apps/settings/js/icc.js#L825
> 
> Is this what happens?

After tone is finished playing, a TR should be sent but we're not seeing it. Can you please try to reproduce this with the PDU I originally shared in Comment 0?

As for dialog closing after the tone plays, that's a UI decision but I do think it makes sense to dismiss the dialog once a TR has been sent (whether it's by user pressing a button on the screen or because of the TR that needs to be sent after the tone finishes).

> 
> 
> Looking the traces a response with 0 has been sent and then a new try to
> response had been done but as it had been responded (0) no command to
> response is displayed.
How are things going here?
(Reporter)

Comment 19

6 years ago
Fernando, have you been able to reproduce this? Let me know if there are any other logs you need to me to collect. This is pretty easy to reproduce though so the quickest might just be for you to try it out.
Flags: needinfo?(frsela)
Fernando is on Holidays this week, he will be back on Monday
(Reporter)

Updated

6 years ago
Duplicate of this bug: 847035
Created attachment 728959 [details]
Fixed timeout response
Attachment #728959 - Flags: review?(kaze)
Flags: needinfo?(frsela)
(Reporter)

Comment 23

6 years ago
Hi Fernando,

After manually pulling in attachment 728959 [details] and https://github.com/mozilla-b2g/gaia/commit/aafcb4fbcfb303718fdd824ccd7f30e94943c621 onto a v1.0.1 branch, this issue is now fixed!

Please make sure that both changes are pulled into v1.0.1.
(In reply to Carol Yang from comment #23)
> Hi Fernando,
> 
> After manually pulling in attachment 728959 [details] and
> https://github.com/mozilla-b2g/gaia/commit/
> aafcb4fbcfb303718fdd824ccd7f30e94943c621 onto a v1.0.1 branch, this issue is
> now fixed!
> 
> Please make sure that both changes are pulled into v1.0.1.

\o/

Thanks for feedback :)
Comment on attachment 728959 [details]
Fixed timeout response

looks good to me, thanks for your patch.
Attachment #728959 - Flags: review?(kaze) → review+
Merged on master:
https://github.com/mozilla-b2g/gaia/commit/0297a1ac0657c714e695eb3ea02a3f2f45658ce4
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(In reply to Fabien Cazenave [:kaze] from comment #26)
> Merged on master:
> https://github.com/mozilla-b2g/gaia/commit/
> 0297a1ac0657c714e695eb3ea02a3f2f45658ce4

Thanks! 

jhford, or whoever is doing the uplift, can you ensure also commit https://github.com/mozilla-b2g/gaia/commit/aafcb4fbcfb303718fdd824ccd7f30e94943c621 is uplifted based on comment 23.
Flags: needinfo?(jhford)
v1-train: 8d9c59a0d8a08ac2beaf2522332f118707f347ea
v1-train: 26b463f14caa11e0fc64fda09a17054da4bea68b
v1.0.1: 39b7eb2788c34fb57afd2b81d944e33129090fb6
v1.0.1: 0a9f78bffafda93a159c1f502e8b110c2f49a500
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
Flags: needinfo?(jhford)

Comment 29

6 years ago
Build ID: 20130329070203 
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/5cc5df16447a
Gaia: 26b463f14caa11e0fc64fda09a17054da4bea68b

Verified as fixed in V1 train. After tone is finished playing, a TR is sent.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.