Closed Bug 899236 Opened 6 years ago Closed 6 years ago

[B2G][Lockscreen][Leo] Camera icon is not displayed on the lockscreen when the passcode is enabled

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:leo+, b2g18 verified, b2g-v1.1hd fixed)

RESOLVED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- verified
b2g-v1.1hd --- fixed

People

(Reporter: ssuresh, Assigned: mihai)

References

Details

(Keywords: regression, smoketest)

Attachments

(3 files)

Attached image Screenshot
Description:
According to the Specs in Bug 867219, the lockscreen should have a camera icon displayed when passcode is enabled. Currently when user access the lockscreen with passcode enabled, the keypad appears but camera icon is not displayed

Repro Steps:
1) Updated Leo to Build ID: 20130729070226
2) Flash the device to latest build
3) Enable Phone lock under settings 
4) Lock the Dvice
5) Unlock the device, observe that Camera icon is not shown on Lockscreen

Actual:
Camera icon is not displayed on the lockscreen when the passcode is enabled

Expected:
Camera icon is displayed on the lockscreen when the passcode is enabled

Environmental Variables
Build ID: 20130729070226
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8135299f3efd
Gaia: 7aaffc8ccb6cf7ddd1e97943c108f1cb9eae5de0
Platform Version: 18.1
RIL Version: 01.01.00.019.171 

Notes:
Repro frequency: 100% 
See attached : Screenshot
Notes : Reproduces on both Moz and Com RIL
Can we get a regression range here? We need confirmation this worked before.
blocking-b2g: --- → leo?
QA Contact: dkumar
In reply to comment 1 
The camera was present on the lock screen before and than went missing starting 07/14.

Unagi device
Environmental Variables
Build ID: 20130714070208
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f21152a848da
Gaia: 2e711c1fdd2441bda34703cd7d8d3c0f1cc2c396
Platform Version: 18.1
The camera button was removed by the patch for bug 875271 which aimed to fix a UI bug, however I consider that solution to have significant impact on UX and will ask for more details there.
Assignee: nobody → mihai
Depends on: 875271
Hi,

I just checked on my leo with 20130721095109 build, upon lighting up the screen, i get the screenshot you have attached. However, I can press "cancel" and then I get the pull up for unlock/camera buttons. Are you seeing the same thing?
Flags: needinfo?(ssuresh)
blocking-b2g: leo? → leo+
(In reply to Wayne Chang [:wchang] from comment #4)
> Hi,
> 
> I just checked on my leo with 20130721095109 build, upon lighting up the
> screen, i get the screenshot you have attached. However, I can press
> "cancel" and then I get the pull up for unlock/camera buttons. Are you
> seeing the same thing?

I can confirm what you are seeing.
Flags: needinfo?(ssuresh)
I think the problem that happened here is that the implementation in bug 875271 puts the passcode lock before the typical lockscreen UI, which I think is incorrect. That creates a very unnoticable user path for finding the camera functionality from the lockscreen. The right path I think that should be used here is what you would see after hitting cancel in the passcode lock screen:

- Power on phone
- Typical lockscreen appears
** Camera icon takes you to camera app
** Lock icon takes you to passcode lock
Flags: needinfo?(firefoxos-ux-bugzilla)
Btw - put needinfo on UX to ask if my proposal for the UX in comment 6 makes sense here.
Flagging Francis on this critical leo+ lockscreen issue.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
Can we get an update on this? This test case keeps failing the 1.1 smoketest, and there hasn't been any activity since last week.  Thanks.
We need a resolution here quickly. Who is driving this?
Waiting for UX input on this issue before submitting a patch.

There are two possible solutions:

1. Change lock screen unlock order: passcode input screen should come after tapping the unlock button from the regular screen thus allowing the user to open the camera from the regular swipe up panel (as Jason described in comment 6)

2. Put the camera button back in the passcode input screen, tweaking its position so that the time label doesn't wrap (i.e. fix what bug 875271 highlighted)
There was prior work on this in bug #867219. Francis is going to comment further momentarily.
This is blocking leo+, so please submit a patch and get UX review along the way.

(In reply to Mihai Cirlanaru [:mihai][:mcirlanaru] from comment #11)
> Waiting for UX input on this issue before submitting a patch.
> 
> There are two possible solutions:
> 
> 1. Change lock screen unlock order: passcode input screen should come after
> tapping the unlock button from the regular screen thus allowing the user to
> open the camera from the regular swipe up panel (as Jason described in
> comment 6)

This would conflict with the Leo requirement that the user should not have to unlock the device in order to enter the lock code, as raised in bug #867219.
 
> 2. Put the camera button back in the passcode input screen, tweaking its
> position so that the time label doesn't wrap (i.e. fix what bug 875271
> highlighted)

Agreed, we should reintroduce the camera icon, as originally specified in bug #867219, to make it fit. Please submit to Eric Pang for UX review.
Flags: needinfo?(fdjabri)
This patch reintroduces the camera button on the passcode input screen and avoids any regression for the time label wrapping issue highlighted in bug 875271 (you can see a screenshot in the PR).
Attachment #791090 - Flags: review?(akuo)
Attachment #791090 - Flags: feedback?(epang)
Comment on attachment 791090 [details]
Pull Request #11568 - Reintroduce the camera button

Code looks alright.
Attachment #791090 - Flags: review?(akuo) → review+
Thanks for the review, Alive!

Once Eric gives his feedback+, I will land this to master.
This is blocking leo. Please land and we will do follow-up changes if necessary. We are in IOT with 1.1.
Comment on attachment 791090 [details]
Pull Request #11568 - Reintroduce the camera button

Thanks Mihai, looks the way we had it before :).
Attachment #791090 - Flags: feedback?(epang) → feedback+
Landed on master:
https://github.com/mozilla-b2g/gaia/commit/86d7d11b4637977b4131845b311e4348fb42d131
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Issue is resolved on Unagi 1.2 but still repro on leo v1.1 com ril - camera button is still missing on a lock screen with pass-code lock see pic.

Leo Build ID: 20130819041202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/285e2afe2a3b
Gaia: 124ed9737f0f44781cb75f763468f1574f753ac0
Platform Version: 18.1
RIL Version: 01.01.00.019.196 

Unagi Build ID: 20130819040203
Gecko: http://hg.mozilla.org/mozilla-central/rev/c8c9bd74cc40
Gaia: f6de05c135913f2cb790759335875bb1b3c4f9bb
Platform Version: 26.0a1
It still reproduces on v1.1 because it was not uplifted yet...
There is a conflict in apps/system/js/lockscreen.js when I tried to uplift this.  Can you take a look at this?

git checkout v1-train
git cherry-pick -x -m1 86d7d11b4637977b4131845b311e4348fb42d131
Flags: needinfo?(mihai)
(In reply to John Ford [:jhford] -- please use 'needinfo?' instead of a CC from comment #23)
> There is a conflict in apps/system/js/lockscreen.js when I tried to uplift
> this.  Can you take a look at this?
> 
> git checkout v1-train
> git cherry-pick -x -m1 86d7d11b4637977b4131845b311e4348fb42d131

Hi John, I have submitted a PR for v1-train fixing the conflicts: https://github.com/mozilla-b2g/gaia/pull/11620

Since the uplift PR is easy to follow in comparison to the commit on master, feel free to merge it.
Flags: needinfo?(mihai)
v1.1.0hd: b5f322609f9d48a42fec9a0a26e0df565efccabe
v1.1.0hd: 291810f56c245c7f3987bb05e3567f4fca4be2f3
Issue no longer occurs on Leo device. 
Build ID: 20130827041201
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/328b3b8158ee
Gaia: 4b2f1a103d046c92d201e8fcfb1ae224f59e7cf1
Platform Version: 18.1
Camera icon is displayed on the lock screen as expected when the pass code is enabled.
Blocks: 898261
You need to log in before you can comment on or make changes to this bug.