1119162 - [Flame][Lock Screen]When you tap the "cancel" key in emergency call page, the device will back to lockscreen.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[SandKing]

Attachment: Bug video:1857.mp4

[1.Description]:
[Flame][v2.2][Lock Screen]Enable "Passcode lock" in "Settings"-> "Screen lock", then tap the "cancel" key in emergency call page, the device will back to lockscreen.
Found Time:18:57
Bug video:"1857.mp4"
Bug log:"logcat_1857.txt"

[2.Testing Steps]: 
1. Enable "Passcode lock" in "Settings"-> "Screen lock".
2. Press "Power" key to lock the device.
3. Unlock device and press "EMERGENCY CALL"  key.
4. Tap the "Cancel" key.

[3.Expected Result]: 
4. The device should back to input passcode page. 

[4.Actual Result]: 
4. The device will back to lockscreen.

[5.Reproduction build]: 
Flame 2.2 build:
Gaia-Rev        69ac77cfa938fae2763ac426a80ca6e5feb6ad25
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/33781a3a5201
Build-ID        20150107010216
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150107.044401
FW-Date         Wed Jan  7 04:44:12 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]:
Free Test

Comment 1

[SandKing]

Attachment: Bug log: logcat_1857.txt

Comment 2

[Eric Chang [:ericcc] [:echang]]

Set 2.2? for regression

Comment 3

[Coler]

Hi Eric,
   We have executed a regressionwindow-wanted test. and the repro information is below, please check.

Last Working Environmental Variables:

Device: Flame2.2
Gaia-Rev        0dfc1996eb583c8b507a82bf6b8319624bba23ea
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/80e18ff7c7b2
Build-ID        20141030040201
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141030.071745
FW-Date         Thu Oct 30 07:17:56 EDT 2014
Bootloader      L1TC000118D0

First Broken Environmental Variables:

Device: Flame2.2
Gaia-Rev        8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/e0b505a37b1c
Build-ID        20141030160200
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141030.192246
FW-Date         Thu Oct 30 19:22:57 EDT 2014
Bootloader      L1TC000118D0

Comment 4

[howie [:howie]]

Hi Hung, can you confirm what's the correct behavior of lockscreen here? Thanks.

Comment 5

[Hung Nguyen]

Deferring to Jacqueline.

Comment 6

[Jacqueline Savory [:jsavory] UX]

I believe that if the user is going to the emergency call from the passcode screen, they should return to passcode screen when they tap cancel. ni? on Rob to confirm.

Comment 7

[Rob MacDonald [:robmac]]

(In reply to jsavory from comment #6)
> I believe that if the user is going to the emergency call from the passcode
> screen, they should return to passcode screen when they tap cancel. ni? on
> Rob to confirm.

I agree with Jacqueline. The user should be returned to the passcode screen. Thanks!

Comment 8

[Eric Chang [:ericcc] [:echang]]

Thanks Lance, remove ni.

Comment 9

[Eric Chang [:ericcc] [:echang]]

Typo, I mean Coler, thanks.

Comment 10

[Greg Weng [:snowmantw][:gweng][:λ]]

Things need to be clarified with some technical difficulties:

1. There are actual two secure apps: Emergency Call & Secure Camera. If we make Emergency Call could Cancel to the passpad, what's about Secure Camera? Since to leave Secure Camera user could only press the 'home' and the hardware power button, both these buttons would lead to kill the app and return to the slider, since in the keypad mode we intentionally did that. Moreover, since user could press home/power button to kill the EmergencyCall app, too. Should we violate the rule to show no keypad when pressing home/power button while user kills the app via these way?

2. Secure Camera now is with actually two entries: one is from the icon near the Date & Time header, which is existing when the pad risen. Another entry is to slide the Slider to left to invoke the secure app, and thus the passpad would not show itself. If according to 1. we decide to let secure app returns to the keypad, what about the Securea Camera launched because of the sliding? Since when user slided it there is no keypad on the LockScreen, so to return to the keypad would be as strange as user see no pad after the camera/emergency-call app get closed.

3. Technical issues: we may need to keep a table for recording which app launched from which entries, since we would have:

a. EmergencyCall - launched by the keypad - closed-by-homebutton  - show the slide
b. EmergencyCall - launched by the keypad - closed-by-powerbutton - show the slide
c. EmergencyCall - launched by the keypad - closed-by-Cancel      - show the keypad
d. SecureCamera  - launched by the icon   - closed-by-homebutton  - show the slide/keypad (?)
e. SecureCamera  - launched by the icon   - closed-by-powerbutton - show the slide/keypad (?)
f. SecureCamera  - launched by sliding    - closed-by-homebutton  - show the slide/keypad (?)
g. SecureCamera  - launched by sliding    - closed-by-powerbutton - show the slide/keypad (?)

And another issue is currently there is no way to let LockScreen know whether the app is killed via homebutton or powerbutton, or by the button *inside* the app (the "cancel"). So if we need to distinguish these actions we may need some nasty works (capture home/power buttons before it kill the app?).

Therefore, I think this deserves more consideration based on schedule & technical issues. We may need to have more discussions on this bug. So I NI Tim to see if he has further opinions.

(BTW, I think the previous behavior is "correct" is because some keypad control bugs, which occasionally makes it behavior "right", since we never listed all cases like this comment, so it must not be implemented intentionally correct.)

Comment 11

[howie [:howie]]

Triage: minor behavior not blocking.

Comment 12

[Greg Weng [:snowmantw][:gweng][:λ]]

Brief summary from a recent offline discussion:

1. We tend to merge SecureWindowManager + LockScreenWindowManager, since in cases like this it shows the states of these two windows are highly dependent. For example, home button event means to close the secure window and return to the main panel of LockScreen, which therefore belongs to both managers.

2. We should first refactor our LockScreen states with the new architecture, so that we could avoid adjust the current routing mechanism and encounter the possible regressions. The bug is Bug 1115311, but it's only the very first part and we need to do lots of work.

Comment 13

[SandKing]

Attachment: New log: logcat_0535.txt

Hi Eric,
This bug still exists on latest Flame 2.2&3.0 and Nexus_5 V2.2&3.0,
Same STR with comment0
Found time: 05:35

Nexus_5 3.0 build:(Fail)
Build ID               20150429010205
Gaia Revision          6e35b0948c42a4398b8a5916015de167121683a1
Gaia Date              2015-04-28 16:06:07
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4
Gecko Version          40.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150429.044325
Firmware Date          Wed Apr 29 04:43:46 EDT 2015
Bootloader             HHZ12f

Nexus_5 2.2(Fail)
Build ID               20150429002501
Gaia Revision          1b7aa7e60788668ed09abf76022dfa231dbe88d4
Gaia Date              2015-04-28 19:36:06
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d38ff4717f39
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150429.040217
Firmware Date          Wed Apr 29 04:02:34 EDT 2015
Bootloader             HHZ12f

Flame 2.2(Fail):
Build ID               20150429002501
Gaia Revision          1b7aa7e60788668ed09abf76022dfa231dbe88d4
Gaia Date              2015-04-28 19:36:06
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d38ff4717f39
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150429.035717
Firmware Date          Wed Apr 29 03:57:29 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0(Fail):
Build ID               20150429010205
Gaia Revision          6e35b0948c42a4398b8a5916015de167121683a1
Gaia Date              2015-04-28 16:06:07
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150429.043837
Firmware Date          Wed Apr 29 04:38:48 EDT 2015
Bootloader             L1TC000118D0

Comment 14

[Eric Chang [:ericcc] [:echang]]

Suggest to make it a backlog item, thank you.

Comment 15

[howie [:howie]]

Thanks Eric, this is already tracking +, which is a higher priority item in backlog.

Comment 16

[BMO Automation]

Firefox OS is not being worked on