Created an attachment (id=986303) find my device DEFECT DESCRIPTION: MS lock, Input 5678 can not unlock, but input 1234 can unclock. REPRODUCING PROCEDURES: 1.Settings->Firefox Accounts->Sign in 2.Find My Device->Turn on Enable Find My Device 3.Tap find.firefox.com->Sign in Firefox Accounts 4.Lock the MS from website, set the password 1234 -> MS lock, Input 1234 unlock 5.Lock the MS from website again, set the password 5678 -> KO EXPECTED BEHAVIOUR: Input 5678 can unlock. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE:100% Number: 0752-2639306(61306) For FT PR, Please list reference mobile's behavior:

https://find.firefox.com First time use the FMD on PC or Android Phone : 4 steps: 1 Sign in Firefox account. 2 Tap lock button. 3 Input the notice text. 4 Set the password. Then MS will lock. First time use the FMD on Firefox has the same behavior. Second time use the FMD on PC or Android Phone : 3 steps: 1 Sign in Firefox account. 2 Tap lock button. 3 Input the notice text. Then MS will lock. Don't need set the password again. But the second time use the FMD on Firefox: 4 steps: 1 Sign in Firefox account. 2 Tap lock button. 3 Input the notice text. 4 Set the password. Then MS will lock. Need set the password again. But the password not work as well.

any updates?

Hi Alexandre: Could you please help check this issue? Thanks!! Shawn

I don't understand the status between comment 0 and comment 2.

FYI, I have no time to work on this for now.

Hi Norry, qawanted for Woodduck 2.0M and Flame 2.0/2.1/2.2. Thanks!

It appears to me that comment 0 and comment 2 are reporting two separate issues, but I'm not sure I understand the latter. Comment 0 is about how you can't set 5678 as a passcode when locking when you already have 1234 as a passcode. That's by design: we never override the passcode when one is already set on the device. However, I wonder if you should have seen the passcode input at all in the website; that may be a front-end bug, perhaps. Comment 2 seems to be about how you get a passcode input when locking from the device itself, but not the website, when a passcode is already set on the device. Again, I suspect you should not have seen the input on either interface. :nchapman, should the passcode input have been hidden in the scenarios above? Or do you currently always ask for a passcode?

Triage: This is by design for now and we consider enhance in the future. Howie, Can you also take a look? Thanks!

Comment 0 is about how you can't set 5678 as a passcode when locking when you already have 1234 as a passcode. When you use browser of Android or PC can't set passcode twice. But use browser of firefox phone can set passcode twice.

I couldn't reproduce this consistently today, but I did get asked for the passcode a few times, even when the device already had a passcode. This happened both when using a single browser to issue commands, and when alternating between desktop Firefox and FxOS's browser. So this looks like some sort of synchronization issue where the web interface is not aware of the fact that the device already has a passcode, and requests a new passcode. This sounds like a bug, as I expected to not get asked for a passcode in that situation.

(In reply to Guilherme Gonçalves [:ggp] from comment #11) > I couldn't reproduce this consistently today, but I did get asked for the > passcode a few times, even when the device already had a passcode. This > happened both when using a single browser to issue commands, and when > alternating between desktop Firefox and FxOS's browser. > > So this looks like some sort of synchronization issue where the web > interface is not aware of the fact that the device already has a passcode, > and requests a new passcode. This sounds like a bug, as I expected to not > get asked for a passcode in that situation. Hi Guilherme: We are expecting the passcode can be changed remotely. The reason is, it will be more secure if user did lost his/her phone, and would like to change the passcode remotely. Does that make more sense, or some other thoughts?

(In reply to shawn ku [:sku] from comment #12) > Does that make more sense, or some other thoughts? I remember that this behavior was definitely contentious in the past, and it's possible that it will still change in future releases; :6a68 will know if that's the case. Either way, this would be a feature request and most likely out of scope for 2.0. I believe the reason things are the way they are boils down to us trusting the user's passcode more than their FxA password. If I remember correctly, we were worried about an attacker gaining control over a user's Firefox account and proceeding to use that to lock and hijack the users phone, using FMD as a ransomware of sorts. That reasoning also motivates the fact that we cancel most commands (track, ring) upon a successful unlock -- we basically assume it will be harder to steal a device and change its passcode than it is to take control of an account. Whether that assumption is reasonable or not is still up for discussion for later releases, though.

Though I believe we should be using this bug to discuss issue I pointed out in comment 11, I'm CC-ing :vishy because comment 13 raises product-related questions.

This issue occur ons Flame 2.1, the user is prompted to enter a pin every time they lock from the website, but the pin does not change on the phone. Environmental Variables: Device: Flame 2.1 BuildID: 20141204133046 Gaia: 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko: 8b92c4b8f59a Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 This issue does not occur Flame 2.2 and 2.0. The user must manually disable pin lock on the phone before they are given the option to enter a new one on the website. When a new pin is entered, it works correctly on the phone. Environmental Variables: Device: Flame 2.2 BuildID: 20141205040650 Gaia: 529c5fcd234ffd108b57629673ca97c2ef73376d Gecko: 18188c19a3c3 Version: 37.0a1 (2.2) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Environmental Variables: Device: Flame 2.0 BuildID: 20141204171150 Gaia: 856863962362030174bae4e03d59c3ebbc182473 Gecko: e40fe21e37f1 Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

[Tracking Requested - why for this release]: This is opened by partner and this completes the feature of FindMyDevice. Please consider this as high priority.

Hi Josh - The discussion here is all over the place. I don't have time to help with this right now, but can you please clarify exactly what the bug is? What are the STR and expected/actual result? Thanks - Jared

Hi Jared, I think there are feature request mix bug here. :) 1. The original partner reported issue was that FMD website cannot remotely change password on device if device already have one. (comment 10). However per comment 6 and comment 13 from Guilherme, this is currently by design. 2. Guilherme then found bug (comment 11) and also confirmed by Jayme per comment 15 (only on 2.1) that user is prompted to enter a new password every time when they lock device from FMD website, but the new password does not change on the phone. I think issue 1 and 2 are related closely. If issue 1 is by design, we should fix issue 2 on 2.1 that we should not prompt user to enter new password when they lock device from FMD website. Maybe we should open a new bug against 2.1 since the discussion here is already fuzzy. How do you think? Thanks!

:josh, thanks so much for clarifying this. I'm responsible for the front-end of the web site. I looked into it yesterday, and we do not show the option to set the passcode if the device is reporting that it already has a passcode. Unfortunately this means that if the device is not responding for any reason, we will continue to show the passcode dialog until the device reports back that it set the passcode. We may want to change this behavior. We also need to do some additional testing to see if there are scenarios where the passcode state isn't being properly transmitted from the device, through the server, to the web front-end. It seems like a new bug against 2.1 would be useful, but I'll defer to :_6a68 about that :). Thanks! Nick

Hi Josh, Thanks for the explanation. I think opening a new bug is probably the best approach, as it will make it much easier to read the history and understand exactly what we are fixing ^_^ If this bug (comment 11) only reproduces on 2.1, but not 2.0 or 2.2, it seems like it must be a client bug, not a bug with the website, since all three branches hit the same website. I'd guess that the bug is due to some patch that was uplifted to 2.0 but not 2.1, something like that. So, feel free to reopen against the client component and nominate to block - I do want to be sure the triage process feels the bug is important enough to be worth the risk of changing the code. FMD has very limited dev and QA resources, so any change carries significant risk. If the bug is approved to block 2.1, the FMD peers can arm wrestle to see who takes it on, since AFAIK we all have other core duties ;-) Cheers, Jared

[Blocking Requested - why for this release]: Hi Bhavana, This is bug against FMD happen on 2.1 per comment 18, 19 and 20. Could you help to triage whether this is blocker for 2.1? Thanks!

my vote is to open a new bug with the STR specifically for 2.1. as :_6a68 mentions, this seems to be a client issue. There is a larger product question on whether the website should ignore the device lock code and override it. if state maintenance is an issue we could change the functionality. However, that should be considered a feature request.

(In reply to vkrishnamoorthy@mozilla.com [:Vishy] from comment #22) > my vote is to open a new bug with the STR specifically for 2.1. as :_6a68 > mentions, this seems to be a client issue. Vance, please request partner to file a new bug based on the recent comments with STR, clearing the blocking nom for now on this. NI :ktucker to see if QA can file this bug with STR that is 2.1 specific. > > There is a larger product question on whether the website should ignore the > device lock code and override it. if state maintenance is an issue we could > change the functionality. However, that should be considered a feature > request.

This seem to be covered in bug 1094700 Also, it is being reported to me that this issue does indeed occur on 2.0 and 2.2 but the repro rate is really low. The testers will attach video of this occurring.

Here is a video of this issue occuring on Flame 2.0, as mentioned in comment 24: http://youtu.be/zg5oz-28YF8

Firefox OS is not being worked on