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)
Tracking
(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)
People
(Reporter: mikehenrty, Assigned: Eli)
References
Details
(Whiteboard: [systemsfe])
Attachments
(2 files)
369.98 KB,
image/png
|
Details | |
46 bytes,
text/x-github-pull-request
|
kgrandon
:
review+
fabrice
:
approval-gaia-v2.1+
|
Details | Review |
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.
Reporter | ||
Comment 1•10 years ago
|
||
[Blocking Requested - why for this release]:
Phone becomes unusable after going to the camera from passcoded lockscreen.
blocking-b2g: --- → 2.1?
Reporter | ||
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
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)
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → eperelman
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → 2.1 S5 (26sep)
Reporter | ||
Comment 5•10 years ago
|
||
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.
Assignee | ||
Comment 6•10 years ago
|
||
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.
Reporter | ||
Comment 7•10 years ago
|
||
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.
Assignee | ||
Comment 8•10 years ago
|
||
Attachment #8490468 -
Flags: review?(kgrandon)
Comment 9•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 10•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → fixed
Keywords: checkin-needed
Resolution: --- → FIXED
Assignee | ||
Comment 11•10 years ago
|
||
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 12•10 years ago
|
||
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+
Comment 13•10 years ago
|
||
Comment 14•10 years ago
|
||
please verifyme on master and 2.1 this is fixed.
Flags: needinfo?(jmitchell)
Keywords: verifyme
Comment 15•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Flags: in-testsuite?
Assignee | ||
Updated•10 years ago
|
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•