1117656 - [FFOS7715 v2.1][STK]USAT case 27.22.4.8.1 SET UP MENU SEQ 1.1 fail.

Status: RESOLVED WONTFIX

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

Description

[jinghua.xing]

[Testing Steps     ]:USAT case 27.22.4.8.1 SET UP MENU SEQ 1.1 SET UP MENU and MENU SELECTION, without Help Request, Replace and Remove a Toolkit Menu

[Expected Result  ]:case pass

[Test Result      ]:the second level Menu can't directly pop  by clicking on the first menu in Tookit Menu, you must quit and re entered.

Comment 1

[jinghua.xing]

There is also one failed for this issue:

[Testing Steps     ]:USAT case 27.22.4.8.1 SET UP MENU SEQ 1.1 SET UP MENU and MENU SELECTION, without Help Request, Replace and Remove a Toolkit Menu

[Expected Result  ]:Remove the menu "Toolkit Menu" from its menu system

[Test Result      ]:The terminal does not remove the "Toolkit Menu"

Comment 2

[jinghua.xing]

Attachment: stk_setupmenu.patch

I have tried to make a patch for this case. 

But I also have a problem, if we were in the second menu of STK,and we receive an the 1.1.3 command to remove the menu "Toolkit Menu" from its menu system. What should we do next, display a message to show the STK menu is removed ? Especially in DSDS devices.

Comment 3

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Nice question, but I think this isn't a technical one, it's a UX one.

Noemi, what do you think? should UX take a look to this?

(In reply to jinghua.xing from comment #2)
> Created attachment 8544417 [details] [diff] [review]
> stk_setupmenu.patch
> 
> I have tried to make a patch for this case. 
> 
> But I also have a problem, if we were in the second menu of STK,and we
> receive an the 1.1.3 command to remove the menu "Toolkit Menu" from its menu
> system. What should we do next, display a message to show the STK menu is
> removed ? Especially in DSDS devices.

Comment 4

[Noemí Freire (:noemi)]

Hi,

Francis, could you please give some guidelines here?. (please, feel free to forward this request whoever you consider) Thanks!

Comment 5

[Francis Djabri [:djabber]]

Hi Noemi, 

Happy to help, but could I have a bit more context here? Do you have any more details about what a 1.1.3 command is? Generally any destructive action requires a confirmation but this is probably not one of those cases.

Comment 6

[Noemí Freire (:noemi)]

Attachment: ts_102384v060500p.pdf

Hi,
Please refer to "27.22.4.8.1.4.2 Procedure
Expected Sequence 1.1 (SET UP MENU and MENU SELECTION, without Help Request, Replace and Remove
a Toolkit Menu)" section in page 334 of the attached document "ts_102384v060500p.pdf" for seeing the flow in detail. 
In summary:
*1.1.3 command (remove STK menu) is received while users are in the second level os STK menu
*The STK menu is removed, then there would be 2 options:
a- users will just return to Settings menu (users will be able to access again STK menu from there)  
b- a message saying that the previous STK menu has been deleted will be shown before returning to Settings menu

Comment 7

[Francis Djabri [:djabber]]

(In reply to Noemí Freire (:noemi) from comment #6)
> Created attachment 8546542 [details]
> ts_102384v060500p.pdf
> 
> Hi,
> Please refer to "27.22.4.8.1.4.2 Procedure
> Expected Sequence 1.1 (SET UP MENU and MENU SELECTION, without Help Request,
> Replace and Remove
> a Toolkit Menu)" section in page 334 of the attached document
> "ts_102384v060500p.pdf" for seeing the flow in detail. 
> In summary:
> *1.1.3 command (remove STK menu) is received while users are in the second
> level os STK menu
> *The STK menu is removed, then there would be 2 options:
> a- users will just return to Settings menu (users will be able to access
> again STK menu from there)  
> b- a message saying that the previous STK menu has been deleted will be
> shown before returning to Settings menu

Thanks Noemí. If the user can still access the STK menu from the Settings menu after completing the 1.1.3 command (i.e., it is a reversible action), then I don't think there's a need to display a confirmation.

Comment 8

[Noemí Freire (:noemi)]

Hi Francis,

Digging into the code, we have seen two possible scenarios once the "remove STK menu" command is received:

1- "remove STK menu" command is received without any element, in this case users will return to Settings menu and not be able to access STK menu from there. A message here might be useful for them.

2- "remove STK menu" command is received with additional elements, in this case users could return to the previous STK menu level, Settings->STK menu or wherever the operator indicates within the command. No message would be needed in this case.

wdyt?, sorry for the previous misunderstanding.

Noemí.

Comment 9

[Manuel Casas Barrado [:mancas]]

Attachment: Proposed patch

Hey Fernando, could you take a look at the new patch? We need to wait for AUX input, but we can check the main idea and work in the patch in the meantime

Thanks!

Comment 10

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Comment on attachment 8553695 [details] [review]
Proposed patch

Sorry for the delay.

f+ with nits.
Thank you

Comment 11

[jinghua.xing]

Manuel:

Long time no update for this issue, how does this issue going on?

I newly have one question about your patch: an 'stkmenuclose' event will be dispatched when we called the goBackToSettings() function to go to the settings panel. And listen this event in icc_menu.js to restore the current menu to null if the user exits from the icc panel. But we use the currentMenu value using the code: 
>>if (Settings.currentPanel === '#icc' && currentMenu === menu[SIMNumber].iccId) 

So I think if user exit from the icc panel, the code upon will always be false no matter what the currentMenu is. And when the user enters the stk menu again, the currentMenu will be set to the right value. Besides, with your patch, the event can not be dispatched when return to settings main menu by clicking the exit button on the icc panel.

So I think there's no need to dispatch the 'stkmenuclose' event to restore the current menu to null. How do you think about this? Thank you.

Comment 12

[Noemí Freire (:noemi)]

Hi Stephany,

Would you mind to find someone from UX to take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1117656#c8 and give some feedback?. Many thanks!.

Comment 13

[Stephany Wilkes]

Francis is going to take a look.

Comment 14

[Francis Djabri [:djabber]]

(In reply to Noemí Freire (:noemi) from comment #12)
> Hi Stephany,
> 
> Would you mind to find someone from UX to take a look at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1117656#c8 and give some
> feedback?. Many thanks!.

Hi Noemí, 
Sorry for letting this slip through the cracks. I agree with your assessment above. If the user will no longer be able to access the menu after the command, we should issue a confirmation dialog. Without seeing what the UI looks like, I'm not sure what the exact working should be, but it should follow the form:

"Are you sure you want to remove the Toolkit menu" (or however the menu is named in the UI)
Buttons: Cancel Remove (Remove button should be red)

I hope that gives you the info you need but let me know if you need anything else.

Comment 15

[Manuel Casas Barrado [:mancas]]

Hi Francis, could you take a look at the attachment? When we received an order to remove the stk menu, we can't or shouldn't allow the user to decide if he keep or not the toolkit menu. So the best approach, from my point of view (and I think Noemí is ok with this approach), is to notify the user about what has happened, with an information prompt.

WDYT?

Comment 16

[Manuel Casas Barrado [:mancas]]

Attachment: stk_no_menu.png

Comment 17

[Francis Djabri [:djabber]]

Comment on attachment 8585905 [details]
stk_no_menu.png

Looks good! Please add a period at the end of the sentence to follow our general style guidelines.

Comment 18

[BMO Automation]

Firefox OS is not being worked on