Closed Bug 1150258 Opened 9 years ago Closed 6 years ago

[Windows Management][Camera Lockscreen]The user is able to access the homescreen AND camera passcode lockscreen share activity at the same time

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: dharris, Unassigned)

References

()

Details

(Whiteboard: [3.0-Daily-Testing],[2.2-nexus-5-l])

Attachments

(1 file)

Description:
When the user is typing in a passcode on the lockscreen and tries to access the camera while they are typing in the 4th digit of their passcode, the lockscreen camera will appear, but the user will also be on the homescreen. The camera share activity will be have as if it is still on the lockscreen, but the user is able to use the home button to access task manager, and return home.

Prerequisite: Have a passcode enabled (ex:1111)

Repro Steps:
1) Update a Flame to 20150401010204
2) Press the power button twice to enable the lockscreen
3) Swipe right and enter in the first 3 digits of the passcode set
4) Tap the camera icon, the quickly type the 4th passcode digit
5) Take a picture and view the preview
6) press and hold the home button


Actual:
The user is taken to the passcode camera share activity. When the home button is held, the task manager is accessed. If the user selects any app while in the task manager, the camera share activity will still be shown.


Expected:
The user is either brought to the homescreen, OR is brought to the passcode camera share activity. Not both.


Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150401010204
Gaia: 03164bd160809747e6a198e0dba1b7c3ee7789f5
Gecko: 18a8ea7c2c62
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: 8/8
See attached: Could not attain a logcat due to lockscreen and camera being a part of the steps. Video attached - https://youtu.be/YJ7OStebf3o
This issue DOES occur on Flame 2.2, Flame 2.1, and Flame 2.0

The user is taken to the passcode camera share activity. When the home button is held, the task manager is accessed. If the user selects any app while in the task manager, the camera share activity will still be shown.

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat)(Full Flash)
Build ID: 20150331002503
Gaia: cc11248ab69f13e89416c8e6bb2e184187e72088
Gecko: 90a26917ee8f
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat)(Full Flash)
Build ID: 20150330001204
Gaia: 6f39e4e876152de1dcdcc0e7656197f22f105e4b
Gecko: 275ad18f587b
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Environmental Variables:
Device: Flame 2.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150330000204
Gaia: 896803174633fc6acd3fd105f81c349b8e9b9633
Gecko: 0dd313c30aa9
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
qawanted to try for a logcat with wifi debugging.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Keywords: qawanted
Component: Preinstalled B2G Apps → Gaia::System::Window Mgmt
Product: Tech Evangelism → Firefox OS
Attached file logcat.txt
This issue also exist on Nexus5 2.2, 3.0.
Enable wifi and connected, then do the same step with comment0 and get the logcat.txt
Reproducing rate: 5/5

Nexus5 2.2[Affected]
Build ID               20150401002624
Gaia Revision          8b3086ad3963f1707e2bee9094baccafffe161c4
Gaia Date              2015-03-31 21:48:06
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/20b67213a047
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150401.041913
Firmware Date          Wed Apr  1 04:19:28 EDT 2015
Bootloader             HHZ12d

Nexus5 3.0[Affected]
Build ID               20150401160204
Gaia Revision          4bb3a933bd805e8df1e11827cb247754c3565b0b
Gaia Date              2015-04-01 02:06:11
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e044f4d172e2
Gecko Version          40.0a1
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150401.192533
Firmware Date          Wed Apr  1 19:25:49 EDT 2015
Bootloader             HHZ12d
Keywords: qawanted
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing],[2.2-nexus-5-l]
Greg, could you help here?
Flags: needinfo?(gweng)
I think it's a missing racing from very old version, so you can reproduce it from 2.0 to 3.0. One possible solution is if user just tapped the secure camera icon, the pass code should be disabled until the camera got killed.. Or, if the pass code is pressed, the camera should be killed as soon as possible. But I don't know which one for you is more reasonable.
Flags: needinfo?(gweng)
Maybe we need UX input here.
Flags: needinfo?(swilkes)
Seeing if Tif can take this. Tif, please reassign as necessary/appropriate.
Flags: needinfo?(swilkes) → needinfo?(tshakespeare)
The problem is stemming from the fact that once you type in that last 1 after tapping the camera icon, the phone actually becomes unlocked. Thus when you press and hold on the home button you're getting the task manager. (The bug applies to not only preview but also the camera)

If you were to type in 2 after tapping the camera icon (i.e. incorrect passcode), you see the incorrect passcode error just before seeing the camera viewfinder. Pressing and holding the home button does nothing because the phone is still locked.

As I see it, we have a few different options:
1. Remove the camera icon from the passcode screen
2. Prevent the user from tapping on the pin pad once the camera icon is tapped
3. Fix the task manager so that the correct app is opening
4. Have the camera behave the same as if the phone is completely locked - like swiping left on lockscreen (e.g. long press on home does nothing - the user must press home and enter their pin)

I will discuss with robmac tomorrow. Also NI'ing him here.
Flags: needinfo?(rmacdonald)
Hey guys - I discussed with Rob today and this is our preference...

Is it possible to fix the task manager so that it is launching the app instead of returning to camera or preview? (i.e. everything behaves normally as when the device is unlocked)

If this isn't possible - then we would want to disable the keypad so that if the user were to tap on the keypad after tapping the camera icon, nothing would happen (i.e. the full passcode could not be entered and therefore the phone would not get to the unlocked).

Let me know if there are further questions. Thanks!
Flags: needinfo?(tshakespeare)
Flags: needinfo?(rmacdonald)
For task manager NI Alive.

For the disabling I may submit a patch, but I would wait Alive's reply.
Flags: needinfo?(alive)
I don't think we should fix anything in TaskManager because it seems wrong to unlock the phone and open SecureWindow(Camera) at the same time... TaskManager does not take SecureWindow into account, and SecureWindow won't close it when the phone is unlocked.

A(User can open SecureWindow and HomescreenWindow at the same time) -> B(SecureWindow is shown when task manager is opened), since A is already incorrect, why do need to fix it in B?
Flags: needinfo?(alive)
Sorry Alive, I'm not totally following what you're saying. But from the user's perspective this is a bug and the functionality seems broken. From their point of view, they don't know what "SecureWindow is (nor do I for that matter!) or when they are in it or what is should or shouldn't do. To the user, they know that pressing the home button shows the task manager and therefore it should work like its supposed to.

So the question is not whether we should fix it, but CAN we fix it. Can we use non-secure window instead? Or do something to avoid the issue you refer to you in your comment? Again, I don't totally understand what you're saying so it's hard for me to offer realistic suggestions :-/

But as I said in my comment 9, if fixing the task manager isn't possible or way too much effort then we should disable the keypad so the user isn't able to get into this situation.

Thanks Alive!
Flags: needinfo?(alive)
(In reply to Tiffanie Shakespeare from comment #12)
> Sorry Alive, I'm not totally following what you're saying. But from the
> user's perspective this is a bug and the functionality seems broken. From
> their point of view, they don't know what "SecureWindow is (nor do I for
> that matter!) or when they are in it or what is should or shouldn't do. To
> the user, they know that pressing the home button shows the task manager and
> therefore it should work like its supposed to.
> 
> So the question is not whether we should fix it, but CAN we fix it. Can we
> use non-secure window instead? Or do something to avoid the issue you refer
> to you in your comment? Again, I don't totally understand what you're saying
> so it's hard for me to offer realistic suggestions :-/
> 
> But as I said in my comment 9, if fixing the task manager isn't possible or
> way too much effort then we should disable the keypad so the user isn't able
> to get into this situation.
> 
> Thanks Alive!

Let me clarity: my point is let's try to not open the camera on lockscreen and unlock at the same time. It's weird. The two operations are async so we cannot control. Is it a must-have feature to open the camera and go to homescreen at the same time? If not, let's do what Greg stated: don't open camera or don't unlock if camera button is clicked.
Flags: needinfo?(alive)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: