Closed Bug 1067441 Opened 10 years ago Closed 10 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
normal

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
Status: ASSIGNED → RESOLVED
Closed: 10 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.

Attachment

General

Created:
Updated:
Size: