Marcia Knous [:marcia] Reporter
	Description • 10 years ago

Flame, while running:

Gaia   bc6f07c149770c6e6dfbea941ac65138dc364a15
SourceStamp e017c15325ae
BuildID 20140528040205
Version 32.0a1

STR:
1. Setup persona and FX Account with same email.
2. Enable Find my Device on my Flame device.
3. Select "Lost Mode" and enter appropriate information.
4. Enter a passcode that doesn't start with a zero

Actual: Nothing happens

5. Repeat Step 4

Actual: I see the message on my phone and the screen is locked. However, when I enter the passcode that I set, I cannot unlock the device.

	Guilherme Gonçalves [:ggp]
	Comment 1 • 10 years ago

I think this can be fixed by having the server always send the passcode to the client as a string, rather than a number. Maybe I should write some code in the client to be more defensive about it, but I think starting with the server-side change is the way to go.

	Erin Lancaster [:elan]
	Comment 2 • 10 years ago

Needs to be a blocker if qa can still repro.

	Marcia Knous [:marcia] Reporter
	Comment 3 • 10 years ago

I would like to leave this open until we have a staging server to test on.

	Kate Glazko
	Comment 4 • 10 years ago

Can no longer reproduce on 6/16/2014, and 6/17/2014 on Mozilla Central.

However, worth leaving open until Staging Server.

	bhavana bajaj [:bajaj]
	Comment 5 • 10 years ago

Clearing the nom, please renom if you can repro once you have the staging server.

	Marcia Knous [:marcia] Reporter
	Comment 6 • 10 years ago

The behavior I see today using the latest 2.0 Flame build is that I can still send lock codes to the phone repeatedly, but it is always using the first one that I set as the default.

So I am not locked out of my phone as long as I can recall the first string I am sending.

	Guilherme Gonçalves [:ggp]
	Comment 7 • 10 years ago

This is the expected behavior right now: FMD will only override the passcode if (1) the lockscreen is disabled, or (2) the lockscreen is enabled, but passcode lock is disabled. We may change that as part of bug 1035297, though.

	Joshua Mitchell (Inactive)
	Comment 8 • 10 years ago

I believe this qa-wanted tag was already served so I am removing it. If this is in error please do re-add it.

	Marcia Knous [:marcia] Reporter
	Comment 9 • 10 years ago

Resolving as WFM for now, since Comment 7 indicates this is expected.