Header of USSD service appears on the lock screen

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::System::Lockscreen
P3
normal
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: khu, Assigned: gtorodelvalle)

Tracking

unspecified
B2G C3 (12dec-1jan)
x86
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 685063 [details]
USSD

unagi_2012-11-25.zip

STR:
1. Dial *#06# to get IMEI. 
2. Turn off screen. 
3. Turn on screen. 

Expected result:
1. No USSD related information on the lock screen. 

Actual result:
1. The header of USSD information appears in the lock screen. (Attached image)
(Reporter)

Updated

5 years ago
blocking-basecamp: --- → ?
Germán, can you take a look at this, please? :)

I still don't understand why the USSD screen is using an attention screen instead of a popup (PopupManager).
Assignee: nobody → gtorodelvalle
Absolutely ;-) Thanks for detecting it :-)
blocking-basecamp: ? → +
Priority: -- → P3

Updated

5 years ago
Component: Gaia → Gaia::System::Lockscreen
See Also: → bug 815060
All these misbehaviors are due to the fact that the USSD/MMI screen is an attention screen and consequently this bug is highly related (on its cause) to https://bugzilla.mozilla.org/show_bug.cgi?id=815060
(In reply to gtorodelvalle from comment #3)
> All these misbehaviors are due to the fact that the USSD/MMI screen is an
> attention screen and consequently this bug is highly related (on its cause)
> to https://bugzilla.mozilla.org/show_bug.cgi?id=815060

The bug number you linked is the same as this one :) Do you have a different bug number to link?
Flags: needinfo?(gtorodelvalle)
Etienne do you know why USSD is an attention screen?

Is it because it can be called from other applications and so it needs to live on top of the application via such mechanism? If yes that make sense to me. In this case the right fix will involve to cancel the USSD connection when the screen turns off.
Flags: needinfo?(etienne)
The USSD screen was switched to an attention screen while applying "UX guidelines" [1].
I think it had something to do with the fact that the design for classic popups contains an URL bar.

I think (German will correct me) that the STK makes standard calls (not using USSDs)

[1] https://github.com/mozilla-b2g/gaia/commit/41c5a7ef3585a84bebdd080650db4f97957278fc
Flags: needinfo?(etienne) → needinfo?(gtorodelvalle)
Hi guys, I think I do not get etienne@segonzac.info comment regarding the STK, sorry :-(

On the other hand and after discussing it with ferjmoreno@gmail.com , I do not see any reason why the USSD/MMI screen should be an attention_screen. This leaves us 2 options: (1) reformulate it, for example as a dialog (in fact the current implementation of the USSD/MMI is not but a dialog on top of the Communications app (nothing can be done during a USSD/MMI session right now) but dressed as an attention screen) or (2) include a hack, for example, to close the USSD/MMI screen whenever the Communication app looses visibility (because the user is shifting apps, the Home button is pressed, the on/off button is pressed, etc.) and reopen it to its previous state whenever it gains visibility again. Probably option 1 is too risky for V1 and option 2 is too hacky and could be weird visually speaking :-)

Any further comments are more than welcome ;-)
Flags: needinfo?(gtorodelvalle)
(In reply to gtorodelvalle from comment #7)
> Hi guys, I think I do not get etienne@segonzac.info comment regarding the
> STK, sorry :-(
> 
> On the other hand and after discussing it with ferjmoreno@gmail.com , I do
> not see any reason why the USSD/MMI screen should be an attention_screen.
> This leaves us 2 options: (1) reformulate it, for example as a dialog (in
> fact the current implementation of the USSD/MMI is not but a dialog on top
> of the Communications app (nothing can be done during a USSD/MMI session
> right now) but dressed as an attention screen) or (2) include a hack, for
> example, to close the USSD/MMI screen whenever the Communication app looses
> visibility (because the user is shifting apps, the Home button is pressed,
> the on/off button is pressed, etc.) and reopen it to its previous state
> whenever it gains visibility again. Probably option 1 is too risky for V1
> and option 2 is too hacky and could be weird visually speaking :-)
> 
> Any further comments are more than welcome ;-)

Can't we simply close the USSD conversation when the screen turns off? Not doing any visibility trick, just closing it.
(In reply to Vivien Nicolas (:vingtetun) from comment #8)
> (In reply to gtorodelvalle from comment #7)
> > Hi guys, I think I do not get etienne@segonzac.info comment regarding the
> > STK, sorry :-(
> > 
> > On the other hand and after discussing it with ferjmoreno@gmail.com , I do
> > not see any reason why the USSD/MMI screen should be an attention_screen.
> > This leaves us 2 options: (1) reformulate it, for example as a dialog (in
> > fact the current implementation of the USSD/MMI is not but a dialog on top
> > of the Communications app (nothing can be done during a USSD/MMI session
> > right now) but dressed as an attention screen) or (2) include a hack, for
> > example, to close the USSD/MMI screen whenever the Communication app looses
> > visibility (because the user is shifting apps, the Home button is pressed,
> > the on/off button is pressed, etc.) and reopen it to its previous state
> > whenever it gains visibility again. Probably option 1 is too risky for V1
> > and option 2 is too hacky and could be weird visually speaking :-)
> > 
> > Any further comments are more than welcome ;-)
> 
> Can't we simply close the USSD conversation when the screen turns off? Not
> doing any visibility trick, just closing it.

Should we do it also when there is an active USSD session and user clicks on Home Button? The UX effect is quite similar...

Updated

5 years ago
See Also: bug 815060bug 815504
Yeah, in fact another option is what :timdream mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=815504 (directly closing the attention screen when it is being resized to top). In fact, that was what I was referring to in my previous comment, with or without the option to restore the USSD/MMI screen (session) when the user comes back to the Comms app. There are kind of paralel discussions in these 2 bugs which are highly related if not duplicate ;-)
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)
Depends on: 814684

Updated

5 years ago
QA Contact: atsai
Why is this still a bug if bug 815504 comment 10 is implemented? Are we regressed here?
Judging by the time bug 815504 lands and the time two bugs being filed, I think this is a dup of that. Adding qawanted for verification.
Keywords: qawanted
Hi :timdream , it is a bug (although it could be rephrased since it is no longer about the header appearing but the whole USSD/MMI screen) because of https://bugzilla.mozilla.org/show_bug.cgi?id=814684
(In reply to gtorodelvalle from comment #14)
> Hi :timdream , it is a bug (although it could be rephrased since it is no
> longer about the header appearing but the whole USSD/MMI screen) because of
> https://bugzilla.mozilla.org/show_bug.cgi?id=814684

OK, I see what you meant. However, I still don't understand the reason we are not doing bug 815504 comment 10, and instead rely on visibility of the communication app itself instead.

Etienne, as reviewer of the patch in bug 815504, can you give me a reason?
Flags: needinfo?(etienne)
Keywords: qawanted
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #15)
> (In reply to gtorodelvalle from comment #14)
> > Hi :timdream , it is a bug (although it could be rephrased since it is no
> > longer about the header appearing but the wholehttps://bugzilla.mozilla.org/show_bug.cgi?id=814612 USSD/MMI screen) because of
> > https://bugzilla.mozilla.org/show_bug.cgi?id=814684
> 
> OK, I see what you meant. However, I still don't understand the reason we
> are not doing bug 815504 comment 10, and instead rely on visibility of the
> communication app itself instead.
> 
> Etienne, as reviewer of the patch in bug 815504, can you give me a reason?

We _also_ want to hide the MMI attention screen when the screen is turned off/locked, and obviously we don't get a resize event then.
The use case is: start USSD session, tap the power button, tap the power button again -> we don't want the USSD session to be displayed.

From re-reading the various comments on this bug and bug 815504 it looks like if the app frame is setVisible(true) only once the lockscreen is unlocked (as opposed to as soon as the screen is turned on) we cover all the cases.

I think this change makes sense, but if we can't make the lockscreen behave like this for some reason let's stop the madness.

We already have a mechanism to build attention screens that aren't displayed on top of the lockscreen or in the status bar: divs.
Flags: needinfo?(etienne)
With bug 819836 landed, I can no longer see USSD dialog on the lock screen with STR in comment 0. I am closing this bug based on the finding.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 819836
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.