Closed Bug 1067441 Opened 6 years ago Closed 6 years ago

[Soft Home Button] User stuck when opening Camera from Lockscreen with passcode enabled

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S5 (26sep)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: mikehenrty, Assigned: Eli)

References

Details

(Whiteboard: [systemsfe])

Attachments

(2 files)

STR:

1.) Enable lockscreen passcode in settings
2.) Push power button to turn off screen
3.) Push power button again to wake to lockscreen
4.) Slide unlocker left to open camera

Actual results:
Camera displays normally, but instead of SHB bar we see tiny portion of lockscreen which can still be interacted with. If you try to unlock the phone now, the passcode prompt will show up but be mostly obscured by the camera

Expected results:
Either camera is entirely fullscreen, or SHB displays but takes you back to the lockscreen or is disabled.
[Blocking Requested - why for this release]:

Phone becomes unusable after going to the camera from passcoded lockscreen.
blocking-b2g: --- → 2.1?
Rob, what should happen here when the user opens the camera from lockscreen with SHB enabled? Do we display the SHB? What happens when the user taps the SHB?
Flags: needinfo?(rmacdonald)
Hi Michael...

In this instance we should show the SHB in camera as we would normally. However, in the passcode scenario, hitting the home button would return to the lock screen. Also, since the phone was never fully unlocked, the notifications would not be cleared in this instance. In the non-passcode scenario, hitting home would return home as the passcode is not required.

NI me if you have any follow-up questions or concerns.

- Rob
Flags: needinfo?(rmacdonald)
UX bug.
blocking-b2g: 2.1? → 2.1+
Assignee: nobody → eperelman
Status: NEW → ASSIGNED
Target Milestone: --- → 2.1 S5 (26sep)
Actually, thinking about this more, we should probably do whatever we currently do when someone presses the physical home button on the flame when they went to camera from the lockscreen with the passcode enabled.
In looking into this issue, I'm almost positive this has arisen due to my changes in bug 1064595. I would also consider this blocking as this is a regression from how it functioned previously.
Something we should consider is treating times when lockscreen is locked as not having a SHB. I just noticed another issue where if we get an alarm while lockscreen is locked with SHB enabled, we see a similar problem to the attached screenshot.
Comment on attachment 8490468 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24119

This looks good to me. It think we should attempt to write a marionette test for this, so creating a bug to track it, and it might be something that I pick up later this week or next week if it's still open.
Attachment #8490468 - Flags: review?(kgrandon) → review+
Blocks: 1068442
Keywords: checkin-needed
In master: https://github.com/mozilla-b2g/gaia/commit/72262d054ffa5d0d2b5a0033f713149281511aea
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Comment on attachment 8490468 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24119

Requesting uplift to v2.1 as this is blocking and represents a broken and unusable UI.

[Bug caused by] (feature/regressing bug #): bug 1036339
[User impact] if declined: unusable lockscreen UI when paired with SHB
[Testing completed]: yes, manual and automated
[Risk to taking this patch] (and alternatives if risky): low as this patch is entirely CSS styles and JS changes to support adding the styles
[String changes made]: n/a
Attachment #8490468 - Flags: approval-gaia-v2.1?
Comment on attachment 8490468 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24119

Note: I don't see any new automated test landed yet for that.
Attachment #8490468 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
please verifyme on master and 2.1 this is fixed.
Flags: needinfo?(jmitchell)
Keywords: verifyme
Verified fixed on 2.1 and Master - Leaving verifyme tag as that requires checking blocking / depends on issues as well

Environmental Variables:
Device: Flame 2.1
Build ID: 20141006062615
Gaia: 778ebac47554e1c4b7e9a952d73e850f58123914
Gecko: bc87917b3b95
Version: 34.0a2 
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame Master
Build ID: 20141006092353
Gaia: 470826d13ae130a5c3d572d1029e595105485fb0
Gecko: 4534f97c4633
Version: 35.0a1 (Master)
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Status: RESOLVED → VERIFIED
Flags: needinfo?(jmitchell)
Flags: in-testsuite?
Flags: in-testsuite? → in-testsuite+
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.