Closed Bug 1147938 Opened 5 years ago Closed 5 years ago

[STK] SET_UP_MENU cannot be replaced

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.2+, b2g-v2.2 fixed, b2g-master fixed)

RESOLVED FIXED
2.2 S11 (1may)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: cyang, Assigned: selee)

References

Details

(Whiteboard: [caf priority: p2][CR 813805][ft:comms])

Attachments

(3 files)

USAT GCF 27.22.4.8.1.1 (SET UP MENU, Replace and Remove Toolkit Menu)

Steps:
- SET UP MENU proactive command with “Item1”, “Item2”, “Item3”, “Item4”.
- Select “Item2”.
- SET UP MENU proactive command with “One”, “Two”.

Observation:
- Selecting “Item2” on the first menu triggers the second SET UP MENU proactive command, but the UI still shows the stale menu (“Item1”, “Item2”, “Item3”, “Item4”). It is only when I go back to ‘Settings’ and open the ‘Toolkit Menu’ again, that I see the current menu (“One”, “Two”).
Hi Fernando,

Can you please take a look at this?

Note that if there was a SET_UP_MENU proactive command followed by a SELECT_ITEM, the menu will be updated. It is only an issue when one SET_UP_MENU is replaced by another SET_UP_MENU.

Our testers found this via GCF testing but I was able to reproduce it locally by treating SELECT_ITEM as if it was SET_UP_MENU, i.e. make typeOfCommand=37 even when it should be 36.

Thanks,
Carol
blocking-b2g: --- → 2.2?
Flags: needinfo?(frsela)
Whiteboard: [CR 813805]
Whiteboard: [CR 813805] → [caf priority: p2][CR 813805]
Whiteboard: [caf priority: p2][CR 813805] → [caf priority: p2][CR 813805][ft:comms]
Hi Wesley, are you in charge of the STK and triage this? Thanks.
Flags: needinfo?(whuang)
Hi Carol,

Manuel had been working on this topic too (adding him to the loop); We'll try to check this.
Flags: needinfo?(frsela) → needinfo?(b.mcb)
Very likely this will be a blocker, but would like to hear from devs first.
We're very close to FC date (April6th).
Hi Carol, can you provide us the commands you've used to test this feature?

Thanks
Flags: needinfo?(b.mcb)
Flags: needinfo?(cyang)
Sean,
 Please help check this issue in parallel.
Flags: needinfo?(selee)
Please help provide us device/radio log, we want to check the proactive command sequences and PDUs we got from rild/modem.
(In reply to shawn ku [:sku] from comment #7)
> Please help provide us device/radio log, we want to check the proactive
> command sequences and PDUs we got from rild/modem.

Carol, 
Would you please shed the light here?
Clear ni first. I will keep watching this.
Flags: needinfo?(selee)
Hi all,

The PDUs come from the GCF spec 3GPP TS 51.010-4. But you can reproduce this without those specific PDUs. In case you want the exact PDUs, they are:

SET UP MENU proactive command with “Item1”, “Item2”, “Item3”, “Item4”:

D03B810301250082028182850C546F6F6C6B6974204D656E758F07014974656D20318F07024974656D20328F07034974656D20338F07044974656D2034

SET UP MENU proactive command with “One”, “Two”:

D023810301250082028182850C546F6F6C6B6974204D656E758F04114F6E658F041254776F

As I mentioned in comment 1 though, if you have a regular STK card that contains a few level of menus, you can easily reproduce by treating SELECT_ITEM like a SET_UP_MENU. Please see the attached video where to reproduce this issue, I hacked the code to do so.
Flags: needinfo?(cyang)
Sean, please help check comment 10 to see the raw PDUs for issue repo.
Flags: needinfo?(selee)
I am working on this already and will update information here if there is any.
Hi Carol,

In this patch, the UI will be back to main menu of Settings app when receiving SET_UP_MENU proactive command.

Could you help to verify the patch attachment 8594647 [details] [review]?
Thanks a lot.
Flags: needinfo?(selee) → needinfo?(cyang)
(In reply to Sean Lee [:seanlee] from comment #14)
> Hi Carol,
> 
> In this patch, the UI will be back to main menu of Settings app when
> receiving SET_UP_MENU proactive command.
> 
> Could you help to verify the patch attachment 8594647 [details] [review]?
> Thanks a lot.

Hi Sean,

Thanks for the quick turnaround on the fix! I've applied the patch and did see what you had described here. Looks good to me.

Thanks,
Carol
Flags: needinfo?(cyang)
Comment on attachment 8594647 [details] [review]
[gaia] weilonge:seanlee/STK/master/Bug1147938 > mozilla-b2g:master

Hi Fernando,

Could you help to review my patch?
Thank you!
Attachment #8594647 - Flags: review?(frsela)
Hi! Sean,

Since you are working on this case.
Over to you. Thanks

--
Keven
Assignee: nobody → selee
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(whuang)
Attachment #8594647 - Flags: review?(frsela) → review+
Comment on attachment 8594647 [details] [review]
[gaia] weilonge:seanlee/STK/master/Bug1147938 > mozilla-b2g:master

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:
Attachment #8594647 - Flags: approval-mozilla-b2g37?
Hi Bhavna,

Can you please approve this for 2.2?

Thanks,
Carol
Flags: needinfo?(bbajaj)
Flags: needinfo?(bbajaj)
Attachment #8594647 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Comment on attachment 8594647 [details] [review]
[gaia] weilonge:seanlee/STK/master/Bug1147938 > mozilla-b2g:master

Hi bhavana,

This is a gaia patch, so the approval should be approval‑gaia‑v2.2. could you give the approval again? Thank you!

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:
Flags: needinfo?(bbajaj)
Attachment #8594647 - Flags: approval-gaia-v2.2?
Attachment #8594647 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Flags: needinfo?(bbajaj)
You need to log in before you can comment on or make changes to this bug.