USSD/MMI Dialog should close itself when it is being dismissed

RESOLVED FIXED in B2G C3 (12dec-1jan)

Status

Firefox OS
Gaia::Dialer
P3
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: timdream, Assigned: gtorodelvalle)

Tracking

unspecified
B2G C3 (12dec-1jan)

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: interaction, UX-P2)

Attachments

(1 attachment)

STR:

1. go do dialer
2. dial *#06#
3. USSD/MMI dialog will show up, and show your IMEI code
4. Try to dismiss the dialog by pressing home

Expected:

1. dialog dismissed and gone

Actual:

1. the dialog (attention screen) was kept on the active status bar; no style updated however
There are a few issues related to the fact that the MMI/USSD dialog is an attention screen. Etienne, Germán, is there any reason why it should be an attention screen instead of a simple popup?
Flags: needinfo?(etienne)
Whiteboard: DUPEME
Seems much like Bug 809885 but that one is resolved/fixed.

Etienne / Alive, do you think this is a regression or something new?
Whiteboard: DUPEME → dupme
Whiteboard: dupme
I don't think it's a regression. Should be something wrong in USSD implementation. Not system app.
Flags: needinfo?(etienne)
I'll let Etienne and Alive comment on the reasons for the USSD/MMI screen to be an attention screen since somehow I found it this way from the beginning :-)
Please provide better UX for this bug and renominate if needed.
blocking-basecamp: ? → -
Minused because it works as designed.
It was originally implemented as a standard popup but UX decisions led to the change.
As for the home button, it was also part of the original implementation...

This may be a wontfix.

Comment 8

5 years ago
IMHO we cannot allow the phone to be launched with this bug as it makes the phone seem broken.

am going to bring Josh into this discussion as i do not know what UX decisions have lead to this behavior so i cannot advise right now, but we certainly need a resolution.

Josh...?
Severity: normal → major
Flags: needinfo?(jcarpenter)
Priority: -- → P2
Whiteboard: Interaction
I'm not familiar with the UX decision here either. Marco was lead on UX here, I believe.

His spec: https://www.dropbox.com/sh/n9j23qwq7jw8pzy/_hyqXaL8X8

Marking this a UX-P2 to fix for release.

Marco, can you comment?
Severity: major → normal
Flags: needinfo?(jcarpenter) → needinfo?(marcoc)
Priority: P2 → --
Whiteboard: Interaction → interaction, UX-P2
(In reply to Etienne Segonzac (:etienne) from comment #7)
> It was originally implemented as a standard popup but UX decisions led to
> the change.
> As for the home button, it was also part of the original implementation...
> 
> This may be a wontfix.

Alternatively, the USSD dialog can |window.close()| itself when it is being resized to top.

Comment 11

5 years ago
Hi Etienne,

I am trying to define how I can help to resolve this bug by providing a better UX as dscravaglieri@mozilla.com in comment 5 is requesting. 

Could you help my understanding of the current situation by clarifying: 

1) why the attention screen is kept active in the status bar when the home button is tapped
2) what is preventing the attention screen from behaving like other dialogues when the home button is tapped 
3) what issues do you see that are preventing a dev fix from being implemented to the current solution.

thanks.
Flags: needinfo?(marcoc)

Comment 12

5 years ago
just flagging Etienne for a NAI to Marco's comment 11.
Flags: needinfo?(etienne)
(In reply to marcoc from comment #11)
> Hi Etienne,
> 
> I am trying to define how I can help to resolve this bug by providing a
> better UX as dscravaglieri@mozilla.com in comment 5 is requesting. 
> 
> Could you help my understanding of the current situation by clarifying: 
> 
> 1) why the attention screen is kept active in the status bar when the home
> button is tapped

It's by design.

> 2) what is preventing the attention screen from behaving like other
> dialogues when the home button is tapped 

Well then pressing the home button while on a call (the call screen is an attention screen) will hangup the call, pretty **** UX.

> 3) what issues do you see that are preventing a dev fix from being
> implemented to the current solution.

The issue is not with the attention screen, the issue is that the USSD screen has no reason to be an attention screen.
If the USSD UX != from the attention screen UX, the USSD screen should be implemented in-app, with a classic window.open (like it originally was), or even with a simple div.
Flags: needinfo?(etienne)
OK, so I think we all agree that we need to fix this issue. Nominating again.

Question is how to do it, remove the attention screen or hacking it. Thoughts?
blocking-basecamp: - → ?
Flags: needinfo?(21)
(In reply to Daniel Coloma:dcoloma from comment #14)
> OK, so I think we all agree that we need to fix this issue. Nominating again.
> 
> Question is how to do it, remove the attention screen or hacking it.
> Thoughts?

If closing the window on mozvisibilitychange (hidden) solves *all* the issues it's probably the safest bet.
I could give it a try. Just to confirm, are we speaking of just window.closing the USSD/MMI screen whenever the Communications app looses visibility and NOT restoring it when the app gets visibility again??? or would we want to restore the USSD/MMI screen to its previous state? :-) I feel like asking a kid if he wants chocolate or not... :-ppp
Flags: needinfo?(dcoloma)
blocking-basecamp: ? → +
Priority: -- → P3
(In reply to Etienne Segonzac (:etienne) from comment #13)
> The issue is not with the attention screen, the issue is that the USSD
> screen has no reason to be an attention screen.
> If the USSD UX != from the attention screen UX, the USSD screen should be
> implemented in-app, with a classic window.open (like it originally was), or
> even with a simple div.

This seems to be the crux of it. Why did we change from a window.open implementation in the first place?
(In reply to gtorodelvalle from comment #16)
> I could give it a try. Just to confirm, are we speaking of just
> window.closing the USSD/MMI screen whenever the Communications app looses
> visibility and NOT restoring it when the app gets visibility again??? or
> would we want to restore the USSD/MMI screen to its previous state? :-) I
> feel like asking a kid if he wants chocolate or not... :-ppp

I want chocolate... 

What would be the consequences of closing a USSD session when the user switches to another task? I am concerned about use cases such as doing top-ups through USSDs, maybe users might not be aware of the top-up result?
Flags: needinfo?(dcoloma)
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
(In reply to Josh Carpenter [:jcarpenter] from comment #17)
> (In reply to Etienne Segonzac (:etienne) from comment #13)
> > The issue is not with the attention screen, the issue is that the USSD
> > screen has no reason to be an attention screen.
> > If the USSD UX != from the attention screen UX, the USSD screen should be
> > implemented in-app, with a classic window.open (like it originally was), or
> > even with a simple div.
> 
> This seems to be the crux of it. Why did we change from a window.open
> implementation in the first place?

Because window.open opens with a URL bar.(In reply to gtorodelvalle from comment #16)
> I could give it a try. Just to confirm, are we speaking of just
> window.closing the USSD/MMI screen whenever the Communications app looses
> visibility and NOT restoring it when the app gets visibility again??? or
> would we want to restore the USSD/MMI screen to its previous state? :-) I
> feel like asking a kid if he wants chocolate or not... :-ppp

No chocolate. Leaving == Closing.

(In reply to Daniel Coloma:dcoloma from comment #18)
> (In reply to gtorodelvalle from comment #16)
> > I could give it a try. Just to confirm, are we speaking of just
> > window.closing the USSD/MMI screen whenever the Communications app looses
> > visibility and NOT restoring it when the app gets visibility again??? or
> > would we want to restore the USSD/MMI screen to its previous state? :-) I
> > feel like asking a kid if he wants chocolate or not... :-ppp
> 
> I want chocolate... 
> 

I guess IPhone close it (I don't have one to try) and I have not heard anybody complaining about it (so maybe they don't). So let's not give chocolate where it is not needed and keep them for other things.

> What would be the consequences of closing a USSD session when the user
> switches to another task? I am concerned about use cases such as doing
> top-ups through USSDs, maybe users might not be aware of the top-up result?

I guess as long your topup number is not validated you won't burn it. Also you will still be able to receive a phone call since the communication app does not loose visibility when a call is received.
Flags: needinfo?(21)
(In reply to Vivien Nicolas (:vingtetun) from comment #20)
> (In reply to Josh Carpenter [:jcarpenter] from comment #17)
> > (In reply to Etienne Segonzac (:etienne) from comment #13)
> > > The issue is not with the attention screen, the issue is that the USSD
> > > screen has no reason to be an attention screen.
> > > If the USSD UX != from the attention screen UX, the USSD screen should be
> > > implemented in-app, with a classic window.open (like it originally was), or
> > > even with a simple div.
> > 
> > This seems to be the crux of it. Why did we change from a window.open
> > implementation in the first place?
> 
> Because window.open opens with a URL bar.

OK, then it seems we can only try the close option unless UX is happy with the URL bar but it seem that was not the case.

> 
> No chocolate. Leaving == Closing.
> 

I want chocolate regardless of the decision on this bug :-)

> (In reply to Daniel Coloma:dcoloma from comment #18)
> > (In reply to gtorodelvalle from comment #16)
> > > I could give it a try. Just to confirm, are we speaking of just
> > > window.closing the USSD/MMI screen whenever the Communications app looses
> > > visibility and NOT restoring it when the app gets visibility again??? or
> > > would we want to restore the USSD/MMI screen to its previous state? :-) I
> > > feel like asking a kid if he wants chocolate or not... :-ppp
> > 
> > I want chocolate... 
> > 
> 
> I guess IPhone close it (I don't have one to try) and I have not heard
> anybody complaining about it (so maybe they don't). So let's not give
> chocolate where it is not needed and keep them for other things.
> 

I think iPhone does not allow you to go out of the session (i.e. the home button does not work, the notification bar cannot be pulled down, etc...). You need to explicitly click a button to close the session.

> > What would be the consequences of closing a USSD session when the user
> > switches to another task? I am concerned about use cases such as doing
> > top-ups through USSDs, maybe users might not be aware of the top-up result?
> 
> I guess as long your topup number is not validated you won't burn it. 


You can also top-up with VISA card and this kind of operations are the ones we should be cautious about when closing a session without user being aware we are going to close it. 

> Also
> you will still be able to receive a phone call since the communication app
> does not loose visibility when a call is received.

In this case, the user should be able to accept or reject the call. If he accepts,  he assumes the call is more important than the USSD session, so he somehows agrees with closing it. If he rejects, the USSD should continue as it was (at least this what iPhone does).

Anyhow, if the only option we have is closing the session automatically, let's go for it... 

Did I mention I wanted chocolate :-P?
Hi, apart that confirming that everyone wants chocolate, except :vingtetun who would probably prefer macarrons :-p , I wanted to confirm that I am currently implementing the closing of the USSD/MMI screen whenever the Communications app looses visibility :-)

Regarding the implications of this closing, maybe :ferjm could shed some light on the implications of closing the USSD/MMI session since the closing of the USSD/MMI page would basically do a window.navigator.mozMobileConnection.cancelMMI()

I'll keep you posted ;-)
Flags: needinfo?(ferjmoreno)
Calling the |cancelMMI()| will close the USSD session if one exists. For the top-up use case that Daniel mentioned in comment 18, cancelling an USSD session doesn't mean that it would also cancel a previously requested top-up. It just means that the user won't receive any result (via USSD) about her request cause the communication channel has been closed, unless the result is communicated by any other channel (usually SMS).

*But, if I am not wrong, we don't need to cancel the USSD session when closing the USSD screen*

We can just close/hide the USSD screen and leave the USSD session active. In case that an incoming USSD with the result of a previous request is received we could show the USSD screen again. This would require some platform work to add a system message notification about an incoming USSD to solve the potential issue of the communication app being killed while the USSD session remains active, which would cause the lost of the incoming USSD message.
Flags: needinfo?(ferjmoreno)
:ferjm, wouldn't it be somehow the version "with chocolate" we were talking about before? This is, restoring the USSD/MMI page status whenever the Communications app gets visibility again... ;-999

Anyhow, I noticed that we had already some support for pending notifications in the USSDManager so restoring the USSD/MMI page to its previous status wasn't that complex. And with all due respect, I went for it ;-)

I made a PR: https://github.com/mozilla-b2g/gaia/pull/6891 , you can have a look a it and try it on your devices :-)

In this implementation, the USSD/MMI page is closed whenever the Communications app looses visibility and restored whenever it gains it again (only if it was close due to this visibility hack). If during the time the USSD/MMI page was closed further messages were received, the last one is shown. If no further messages were received, the last shown message is shown, again.

No need to say all this is a hack. The proper way, in my opinion, would be to show USSD/MMI messages using dialogs or whatever other mechanisms "inside" the Communications app.

Enjoy! :-)
Assignee: nobody → gtorodelvalle
Created attachment 689719 [details] [diff] [review]
Associated PR.
Attachment #689719 - Flags: review?
Attachment #689719 - Flags: review? → review?(etienne)
(In reply to gtorodelvalle from comment #24)
> :ferjm, wouldn't it be somehow the version "with chocolate" we were talking
> about before? This is, restoring the USSD/MMI page status whenever the
> Communications app gets visibility again... ;-999

I am afraid that I am lost with your version namings :| ...

In any case, I didn't mention restoring the USSD/MMI screen status. I am just suggesting not to close the USSD session when closing the USSD/MMI screen so further USSD notifications about the current USSD session can be received by the platform. If that is what we finally decide to do, it would require the platform modifications that I mentioned in comment 23.

>
> Anyhow, I noticed that we had already some support for pending notifications
> in the USSDManager so restoring the USSD/MMI page to its previous status
> wasn't that complex. And with all due respect, I went for it ;-)
> 
> I made a PR: https://github.com/mozilla-b2g/gaia/pull/6891 , you can have a
> look a it and try it on your devices :-)
> 
> In this implementation, the USSD/MMI page is closed whenever the
> Communications app looses visibility and restored whenever it gains it again
> (only if it was close due to this visibility hack). If during the time the
> USSD/MMI page was closed further messages were received, the last one is
> shown. If no further messages were received, the last shown message is
> shown, again.
>

I just gave a quick look to the PR, but it seems that you are indeed canceling the USSD session when closing the screen, so no message would be received.
Anyway, even if you don't cancel the session when closing the screen, I am afraid that the support for pending notifications won't be enough to handle new possible USSD notifications. Note that the communication app might get killed and in that case the notifications would be lost.
Ups, you are absolutely right regarding the cancelling ;-) I though I had done it. Sorry!

Regarding the killing of the Communications app, my USSD/MMI super-powers cannot fight against that... :-p I meant that further messages received would be shown if the Communications app is not visible, but alive... :-p
Fixed in the PR (https://github.com/mozilla-b2g/gaia/pull/6891) Thanks for the catch, :ferjm !
Commented on github.
:etienne 's comments included in PR... :-) Ready for merge?
Thanks German. I'd like to hear what is the final product decision based on the issues that I've mentioned in my previous comments before merging the patch. That is: with the current patch, even if we don't cancel the USSD session, since there are high possibilities that the communication app is killed while it is hidden, we might loose replies for previous USSD requests (like the top-up ones). To solve this we would need to modify the platform implementation to add a system message for incoming USSDs.
Flags: needinfo?(dcoloma)
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #31)
> Thanks German. I'd like to hear what is the final product decision based on
> the issues that I've mentioned in my previous comments before merging the
> patch. That is: with the current patch, even if we don't cancel the USSD
> session, since there are high possibilities that the communication app is
> killed while it is hidden, we might loose replies for previous USSD requests
> (like the top-up ones). To solve this we would need to modify the platform
> implementation to add a system message for incoming USSDs.

How difficult would be adding a system message for incoming USSDs and proper handling at the UI level? It seems to me not very straightforward...
Flags: needinfo?(dcoloma) → needinfo?(ferjmoreno)
Comment on attachment 689719 [details] [diff] [review]
Associated PR.

r=me

Last nit (sorry I forgot it the first time) : I think _lastNotification should be called _lastMessage.

cheers!
Attachment #689719 - Flags: review?(etienne) → review+
(In reply to Daniel Coloma:dcoloma from comment #32)
> (In reply to Fernando Jiménez Moreno [:ferjm] from comment #31)
> > Thanks German. I'd like to hear what is the final product decision based on
> > the issues that I've mentioned in my previous comments before merging the
> > patch. That is: with the current patch, even if we don't cancel the USSD
> > session, since there are high possibilities that the communication app is
> > killed while it is hidden, we might loose replies for previous USSD requests
> > (like the top-up ones). To solve this we would need to modify the platform
> > implementation to add a system message for incoming USSDs.
> 
> How difficult would be adding a system message for incoming USSDs and proper
> handling at the UI level? It seems to me not very straightforward...
Flags: needinfo?(ferjmoreno)
Sorry...

I think it would be pretty straightforward for the platform side. It would also require some work on Gaia to implement the handler for the system message. Etienne and German could probably give a better estimation for the Gaia required changes.
Note that adding a system message for incoming USSDs would also allow us to fix Bug 814931, even if it is bb-
I have just included the _lastNotification to _lastMessage change... :-) Thank you very much for your comments, :etienne

Anyhow, before merging the PR and evolving this bug to RESOLVED, :ferjm and myself would like to have :dcoloma OK on the final implementation :-) Basically, the fact that we hide the USSD/MMI attention screen and restore it (in case it was closed due to the visibility handler) whenever it gains visibility again. The USSD/MMI session is NOT closed. In case the further messages are received, they are shown when the screen is re-shown. If not further messages are received, the last already shown one is re-shown again.
Flags: needinfo?(dcoloma)
After discussing it with :dcoloma , we decided to merge the associated PR (https://github.com/mozilla-b2g/gaia/pull/6891) and close this bug.
:ferjm will file a new bug with some follow ups regarding the issues we raised in this bug :-)
Thank you  very much, everyone!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(dcoloma)
Resolution: --- → FIXED
Bug 820292
Blocks: 796657
You need to log in before you can comment on or make changes to this bug.