1097994 - [Lockscreen][Camera] Keypad is displayed before Camera app is launched from the Lockscreen with a passcode.

Status: VERIFIED FIXED

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

Description

[Martin Shuman [:Marty]]

Description:
If the user has a passcode enabled and they launch the Camera app from the homescreen (by sliding left), the number keypad is shown on screen before the camera app opens.

Note: The keypad is not interactive.

Repro Steps:
1) Update a Flame device to BuildID: 20141112040208
2) Enable passcode.
3) Lock the device
4) Press the power button to turn on the screen, then slide left to open the Camera app.
  
Actual:
Keypad is shown when launching Camera app from the lockscreen with a passcode.
  
Expected: 
Keypad is not shown when launching Camera app from the lockscreen with a passcode.
  
Environmental Variables:
Device: Flame 2.2 Master (319MB)
BuildID: 20141112040208 (Shallow Flash)
Gaia: 5ae28ff11b982e2bd7d1aa097cda131536952bdc
Gecko: 688f821edcd4
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
  
Notes:
  
Repro frequency: 7/7
See attached: video clip

---------------------------------------------

This issue does NOT occur on Flame 2.1
Keypad is not shown when launching Camera app from the lockscreen with a passcode.

Environmental Variables:
Device: Flame 2.1 (319MB)
BuildID: 20141112001201 (Shallow Flash)
Gaia: 4c159e75a1568afbbf0c83c1235ec56facfbe87d
Gecko: b9849b3c6aaa
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 1

[Peter Bylenga [:PBylenga]]

High visibility regression.

Requesting a window.

Comment 2

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 1094829 seems to have caused this issue.

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141106235807
Gaia: 99cd108ce3f9579997b13e43da18f81d18cfe5ab
Gecko: 741d8f9bcd7a
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141107003307
Gaia: a36f52d2398e7b97a32b52dbe258a0a65a1ba98a
Gecko: 3eed7db2ff82
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: 99cd108ce3f9579997b13e43da18f81d18cfe5ab
Gecko: 3eed7db2ff82

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: a36f52d2398e7b97a32b52dbe258a0a65a1ba98a
Gecko: 741d8f9bcd7a

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/99cd108ce3f9579997b13e43da18f81d18cfe5ab...a36f52d2398e7b97a32b52dbe258a0a65a1ba98a

Comment 3

[Joshua Mitchell (Inactive)]

possibly caused by Bug 1094829 patch, can you take a look Greg?

Comment 4

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

I think the main issue here is I should re-write the path according to this table:

         w/pwd   w/o pwd
------- -------- ---------
Unlock | keypad |unlock
------- -------- ---------
Camera | secapp |actunlock
------- -------- ---------

Why this didn't happen before is because we usually want to combine the 'unlock' with 'activity unlock', which made the tree structure:

activateUnlock ---- unlock  ---- (done)
               ---- keypad
activateCamera ---- unlock  ---- activity
               ---- secapp

Since we have two 'unlock' behavior and the only difference is it's with or without activity, the path here tends to be combined as:

intend-to-unlock ⓐ---- unlock ⓓ---- activity
                               ⓔ---- (done)
                 ⓑ---- keypad
                 ⓒ---- secapp

Looks like we reduced the decision tree with this version, but it indeed made things more complicated. Since at every checkpoint we need to check much conditions comes from different source, include mozSettings, event details and event types:

ⓐ: event type is 'slide to right' OR  event type is 'slide to left' + if there is no passcode
ⓑ: event type is 'slide to right' AND passcode on
ⓒ: event type is 'slide to left ' AND passcode on
ⓓ: if event detail is an activity
ⓔ: if event detail is null

As you can see, these conditions are crossovers among the two sliding directions and the mozSettings. Some of these code left in the lockscreen.js since very old version, and unfortunately we inherit the same part only in different way to perform them (states & rules). So, I think we need to split these two 'unlock' to solve this bug.

Comment 5

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

Tim: I've tried to add the path as the above comment, but it would add multiple rules and make the manager become more complicated. Although we can split the rules logics to every states as I mentioned, but this would be a duplicated work of our panel-orient state machine. Should I fix this with the new state machine, or I should refactor the current one? If we're not hurried to fix this (although from UX it's a very obvious failure), I suggest to fix it with the new design, which would make the rules and path processing better.

Another choice is to add some quick fix but you know we all hate that, and since this is a bug for 2.2 I think we may have enough time to complete our new state machine, which I'm now working on.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yeah we could do it in 2.2. Please properly mark the dependencies.

Comment 8

[howie [:howie]]

Triage: blocking

Comment 9

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

Attachment: Patch

I fixed as what I commented. Now the unlocking with app (w/ or w/o secure app) would follow another path. Would set review after I add tests.

Comment 10

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

Comment on attachment 8541405 [details] [review]
Patch

Tim: I fixed the test.

Unfortunately the diffs looks weird. If you have problem we could have an offline discussion.

Comment 11

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

OK TBPL is green again:

https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=25ae3829e5d0

Comment 12

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

master: https://github.com/mozilla-b2g/gaia/commit/f2c5dcef558f747e525220f1dfb2da6b07325235

Comment 13

[Shally Li（leave from Mozilla）]

This bug has been verified as "pass" on latest nightly build of Flame v2.2&Master by the STR in Comment 0.

Actual results: Keypad is not shown when launching Camera app from the lockscreen with a passcode.
See attachment: verified_Flame_v2.2.3gp
Reproduce rate: 0/10


Device: Flame v2.2 (Verified, v188) 
Build ID               20150709162504
Gaia Revision          84d0c76370dcd3d25813b00de55194730884355b
Gaia Date              2015-07-09 13:09:14
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e002005dc994
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150709.202124
Firmware Date          Thu Jul  9 20:21:35 EDT 2015
Bootloader             L1TC00011880

Device: Flame v2.2 (Verified, v18D) 
Build ID               20150709162504
Gaia Revision          84d0c76370dcd3d25813b00de55194730884355b
Gaia Date              2015-07-09 13:09:14
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e002005dc994
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150709.202124
Firmware Date          Thu Jul  9 20:21:35 EDT 2015
Bootloader             L1TC000118D0

Device: Flame master (Verified, v18D)
Build ID               20150709160207
Gaia Revision          bdddfe1ebb796e2bc1c048d5c4e0f97f3d06f98b
Gaia Date              2015-07-09 11:58:52
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/adfdc7f29ba7
Gecko Version          42.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150709.193215
Firmware Date          Thu Jul  9 19:32:27 EDT 2015
Bootloader             L1TC000118D0

Comment 14

[Shally Li（leave from Mozilla）]

Attachment: verified_Flame_v2.2.3gp