1108166 - [Find My Device] When trying to disable Find My Device, the toggle is greyed out

Status: RESOLVED FIXED

(Firefox OS Graveyard :: FindMyDevice, defect)

Description

[pete siphantong [:Petes]]

Attachment: fmd.txt

Description:
When the user try to disable Find My Device, the toggle is greyed out and the user will not be able to disable it unless they reset the phone and sign out.

Setup Steps:
1) Setup Steps: Enable Find My Device on the phone > from the desktop browser sign to https://find.firefox.com > Tap lock
  
Repro Steps:
1) Unlock the phone with passcode 
2) Enable airplane mode > try to disable FMD
3) Disable passcode from phone
4) Go to the enable FMD screen> disable airplane mode from notification 
5) Disable FMD with password> go back to settings main page
6) Go back to enable FMD screen > observe the toggle


Actual:
toggle is greyed out
 
Expected: 
toggle function correctly 

  
Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141205040202
Gaia: 529c5fcd234ffd108b57629673ca97c2ef73376d
Gecko: e7f3e6fee15e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


  
Repro frequency: 3/3, 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/14060/
See attached: video, logcat, https://www.youtube.com/watch?v=z9tgc3HTHx8

Comment 1

[pete siphantong [:Petes]]

This issue also reproduces on the Flame 2.1 and the Flame 2.0, trying to disable Find My Device, the toggle is greyed out

Flame 2.1

Device: Flame 2.1 (319mb) (Kitkat Base)(Full Flash)
BuildID: 20141205001201
Gaia: 38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko: 8b92c4b8f59a
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0

Device: Flame 2.0 (319mb) (KitKat Base)(Full Flash)
Build ID: 20141205000201
Gaia: 856863962362030174bae4e03d59c3ebbc182473
Gecko: e40fe21e37f1
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Nominating to block on 2.2. Find my device should be able to be disabled after the user types in their password. The user must reset or erase their device to disable this setting.

Comment 3

[u3woallizom]

Apparently related to Bug Bug 1055624.

Comment 4

[:gerard-majax]

That reminds me of things I hit and that we discard back in 2.0 time ...

Comment 5

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: broken function.

Comment 6

[Kai-Chih Hu [:khu]]

Tarek, is it something that your team is working on? Thank you.

Comment 7

[Kai-Chih Hu [:khu]]

Ian, is it something that you can help? Thanks.

Comment 8

[Ian Bicking (:ianbicking)]

See response in bug 1124335, comment 7

Comment 9

[howie [:howie]]

Hi  Alexandre,  can you help on this? Thanks.

Comment 10

[:gerard-majax]

I don't have time.

Comment 11

[Michael Henretty [:mikehenrty][:mhenretty]]

Guillaume, I've got a fun one for you!

Comment 12

[Guillaume Marty [:gmarty]]

I spent a lot of time playing with this feature and the code. Although I wasn't able to replicate this particular bug using the STR provided, there is clearly something wrong:
* Disabling FMD sometimes works without requiring the password with one of my accounts. But then after a while, the password is required but the switch hangs on on a disabled state.
* When I log in with the other account, I get the disabled FMD switch. When logging to find.firefox.com with that account I get a "Sorry but you don't have any devices." message.

Can someone clarify the points above. Is it the intended behaviour?
Also, Pete, can you retest on the latest master?

Comment 13

[Guillaume Marty [:gmarty]]

Also, Pete, can you try with a newly created account?

Comment 14

[Hermes Cheng (inactive after July 27, 2015)]

Hi Peter, do you know who can help for retesting?

Comment 15

[Gregor Wagner [:gwagner]]

Alex, can you help out here?

Comment 16

[:gerard-majax]

Jared, in apps/settings/js/findmydevice.js, in the _onChangeLoginState method the interactiveLogin boolean is checked. That comes from bug 1021428.

When I reboot my device after reproducing the bug and the button is still partly greyed out, this boolean interactiveLogin is set to FALSE.

I don't have logs of the moment when I try to disable the feature and I get into this state, so I'm not sure sure, but do you know if it's expected at reboot that we get into onChangeLoginState() with interactiveLogin to false, while loggedin is true?

Given that we do nothing if interactiveLogin is false, this may be the lead to fix this bug.

Comment 17

[:gerard-majax]

Enabled Push API debug (setting pref services.push.debug to true), and I see a LOT of spam in the logcat: one push endpoint "hello" every second. This may be linked.

Comment 18

[:gerard-majax]

Attachment: fmd5.log

log with spam of Push.jsm

Comment 19

[:gerard-majax]

When I log out of Firefox Accounts and relogin, findmydevice.can-disable is not set back to true. This depends on the current clientid sent from the server and the state clientid we load from localStorage. My values are somewhat stranges:
 - current clientid: cfffd0f422bfe7a74ae8fa5d5a77702b395cc550506ccceb59067aeea21a54a5
 - state clientid: 75c8a40f489c4627a8f33d455d9f3c62

Comment 20

[Peter Bylenga [:PBylenga]]

Sure, Derek can you take care of the qawanted highlighted in comment 12 and comment 13?

Comment 21

[:gerard-majax]

I'm not sure if I had the exact same issue as reported, but I managed to workaround this. Meawhile, I will need much more debug to make sure.

Comment 22

[:gerard-majax]

Attachment: debug-fmd.patch

Pleas, QA people, apply this and generate as much as log as you can and provide us resulting logcat. Make sure you have enabled the "Gaia traces" in the developper Settings.

Comment 23

[:gerard-majax]

Log after carefully reproducing the STR from a fresh profile. Excerp:

> $ grep -E 'id set to|canDisable' fmd-clean0.log 
> 03-31 20:24:11.747  1627  1627 I GeckoDump: [findmydevice] current id set to: 
> 03-31 20:24:14.517  1627  1627 I GeckoDump: [findmydevice] current id set to: "cfffd0f422bfe7a74ae8fa5d5a77702b395cc550506ccceb59067aeea21a54a5"
> 03-31 20:24:14.517  1627  1627 I GeckoDump: [findmydevice] current state id set to: "cfffd0f422bfe7a74ae8fa5d5a77702b395cc550506ccceb59067aeea21a54a5"
> 03-31 20:24:14.517  1627  1627 I GeckoDump: [findmydevice] calling _canDisable: true
> 03-31 20:27:09.575  1627  1627 I GeckoDump: [findmydevice] current id set to: "75c8a40f489c4627a8f33d455d9f3c62"
> 03-31 20:27:09.575  1627  1627 I GeckoDump: [findmydevice] current state id set to: "75c8a40f489c4627a8f33d455d9f3c62"
> 03-31 20:27:09.575  1627  1627 I GeckoDump: [findmydevice] calling _canDisable: true
> 03-31 20:27:28.965  1627  1627 I GeckoDump: [findmydevice] current id set to: "cfffd0f422bfe7a74ae8fa5d5a77702b395cc550506ccceb59067aeea21a54a5"
> 03-31 20:27:28.965  1627  1627 I GeckoDump: [findmydevice] current state id set to: "75c8a40f489c4627a8f33d455d9f3c62"
> 03-31 20:27:28.965  1627  1627 I GeckoDump: [findmydevice] calling _canDisable: 

So it looks like we are getting mismatch of IDs. Does it rings a bell to any of you?

Comment 24

[:gerard-majax]

Attachment: fmd-clean0.log

Comment 25

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: FMD Logcat with Patch applied

This issue is occurring on Flame 3.0

The toggle will become greyed out in the enabled state, and it is not possible to disable it until device is reset

Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150331010203
Gaia: 251a419e9f7081d782cd752b91b8511f2e299b7d
Gecko: 8af276ab8636
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

As for questions in Comment 12:
1) I also saw that I was able to disable FMD a couple times without a passcode required
2) On multiple occasions I have seen the "Sorry but you don't have any devices." message from the website, with a multitude of different accounts

Comment 26

[:gerard-majax]

Attachment: debug-fmd.patch v2 with tentative fix

more debug and a possible fix

Comment 27

[:gerard-majax]

Attachment: debug-fmd.patch v2 with tentative fix

Comment 28

[:gerard-majax]

Attachment: debug-fmd.patch v2 with tentative fix

Comment 29

[:gerard-majax]

So when we follow the STR and disable Airplane Mode, we do a request against https://find.firefox.com/1/register/ and its response will bring a new clientid (75c8a40f489c4627a8f33d455d9f3c62). Which gets stored locally.

And then later we do a FxA refresh, against https://find.firefox.com/1/validate/, and the response goes back to the original clientid: cfffd0f422bfe7a74ae8fa5d5a77702b395cc550506ccceb59067aeea21a54a5.

Comment 30

[:gerard-majax]

Attachment: fmd-clean2.log.bz2

I need some help to check why we set get the clientid 75c8a40f489c4627a8f33d455d9f3c62: is it normal ? If so, why does the FxA refresh gets back the previous clientid (cfffd0f422bfe7a74ae8fa5d5a77702b395cc550506ccceb59067aeea21a54a5) ?

Comment 31

[:gerard-majax]

Attachment: debug-fmd.patch v2 with tentative fix

Comment 32

[:gerard-majax]

When we are receiving the "wrong" clientid, it's after we performed a POST to /register/ WITHOUT an "assert" parameter.

Comment 33

[Mark Goodwin [:mgoodwin]]

(In reply to Alexandre LISSY :gerard-majax from comment #23)
> So it looks like we are getting mismatch of IDs. Does it rings a bell to any
> of you?

No, I don't recall seeing this before.

Comment 34

[:gerard-majax]

Attachment: debug-fmd.patch v3 workaround

So I've added a workaround tied with state registration state. Following the STR with this patch applied, I do not have any issue anymore.

Comment 35

[:gerard-majax]

Comment on attachment 8586661 [details] [diff] [review]
debug-fmd.patch v3 workaround

Would you mind checking this? Basically I've noticed that during the repro steps, we get into a "registration stale state" that makes us store this wrong clientid in the local state.

Avoiding updating the local state in case of this "registration stale state" makes me able to workaround the issue, but I'm not very confident in not breaking something else.

Comment 36

[GitHub Autolander Bot]

Attachment: [gaia] lissyx:bug1108166 > mozilla-b2g:master

Comment 37

[Mark Goodwin [:mgoodwin]]

Comment on attachment 8586661 [details] [diff] [review]
debug-fmd.patch v3 workaround

Review of attachment 8586661 [details] [diff] [review]:
-----------------------------------------------------------------

This looks reasonable to me. I can't think of a case where doing this would be problematic; I'm leaving ggp's feedback ? since another pair of eyes is a good thing when not completely sure.

Comment 38

[:gerard-majax]

At least, tests are green: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=4c6b656abb2ecc7ddb2e410f330d4a22d3125358

Comment 39

[:gerard-majax]

After speaking on IRC with :ggp, it may be not normal that we get a new clientid from the server. Looking at https://wiki.mozilla.org/CloudServices/FindMyDevice#POST_.2F.3Cversion.3E.2Fregister I see no specific mention whether the |assert| is needed or not.

JR, can you cross check this ? If we send this /register/ request with a deviceid and without an assert, is it normal that we get a new clientid ? If so, should we even be doing this request ?

Comment 40

[:gerard-majax]

Comment on attachment 8586661 [details] [diff] [review]
debug-fmd.patch v3 workaround

Thanks goth, :ggp suggested a nicer workaround, that does the work too.

Comment 41

[:gerard-majax]

Attachment: fmd-clean4.log

> $ grep 'findmydevice registration' fmd-clean4.log 
> 04-01 14:35:38.097  4659  4659 I GeckoDump: [findmydevice] findmydevice registration done, updating state
> 04-01 14:39:14.371  4659  4659 I GeckoDump: [findmydevice] findmydevice registration without assert, discarding clientid
> 04-01 14:39:14.371  4659  4659 I GeckoDump: [findmydevice] findmydevice registration done, updating state

Comment 42

[:gerard-majax]

With the last round of testing on device and pushing to my PR, I have something that works is looks much less like a hack.

Comment 43

[:gerard-majax]

Comment on attachment 8586686 [details] [review]
[gaia] lissyx:bug1108166 > mozilla-b2g:master

Preventive review: we are still waiting for feedback from :jrconlin regarding whether it is even normal that the clientid is changing.

Meanwhile, we may still want this to be more rock solid.

Comment 44

[:gerard-majax]

All green: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=e99a61b2a7bed6cc13bc3fb885a28426ba0bdc8c

Comment 45

[:gerard-majax]

I have branch-specific patches for 2.0, 2.1 and 2.2 (not tested on device):
 - https://github.com/lissyx/gaia/commits/bug1108166_gaia-v2.0
 - https://github.com/lissyx/gaia/commits/bug1108166_gaia-v2.1
 - https://github.com/lissyx/gaia/commits/bug1108166_gaia-v2.1

Comment 46

[:gerard-majax]

Can QA test on their side the proposed PR and maybe even the patches for each branch documented in comment 45 ?

Comment 47

[Guilherme Gonçalves [:ggp]]

Comment on attachment 8586686 [details] [review]
[gaia] lissyx:bug1108166 > mozilla-b2g:master

This sounds very much like a server-side bug, and I'm really not a fan of trying to compensate for those in the client. I think we should try to fix this in the server, and only resort to this patch if there's not enough time for that.

That being said, I think the patch looks very reasonable as a workaround. I've left some comments on the PR and will be happy to r+ once they're fixed. Thanks, :gerard-majax!

Comment 48

[:gerard-majax]

Comment on attachment 8586686 [details] [review]
[gaia] lissyx:bug1108166 > mozilla-b2g:master

Addressed all comments, except the asyncStorage mock.

Comment 49

[Mark Goodwin [:mgoodwin]]

Comment on attachment 8586686 [details] [review]
[gaia] lissyx:bug1108166 > mozilla-b2g:master

Looks good to me.

Comment 50

[:gerard-majax]

(In reply to Guilherme Gonçalves [:ggp] from comment #47)
> Comment on attachment 8586686 [details] [review]
> [gaia] lissyx:bug1108166 > mozilla-b2g:master
> 
> This sounds very much like a server-side bug, and I'm really not a fan of
> trying to compensate for those in the client. I think we should try to fix
> this in the server, and only resort to this patch if there's not enough time
> for that.
> 
> That being said, I think the patch looks very reasonable as a workaround.
> I've left some comments on the PR and will be happy to r+ once they're
> fixed. Thanks, :gerard-majax!

I have been thinking about this and I think we should land it anyway, because:
 - server side issue may or may not be fixed in time
 - it means a bug server side can break the feature of a client
 - a "server side bug" can become a rogue server thus causing others issues
 - in general, I don't see a good reason we should be blindly trusting inputs when we have the ability not to

Meanwhile, I also think we have to fix another part of this problem: what happens for devices/users which are already in the bogus state ? The way this bug gets triggered, I fear the "findmydevice-state" local storage will stay broken.

Comment 51

[Brogan Zumwalt [Inactive]]

With the build made from https://github.com/lissyx/gaia/commits/bug1108166_gaia-v2.2 an issue pops up where at step 5 of the STR, no password prompt is required when disabling FMD after turning off airplane mode from notification tray. At any other time if user attempts to disable FMD they are asked for Firefox Account password. This issue does not occur on latest Flame 2.2 without patched Gaia. Tests were done with cell data only.

On a happier note the issue does not reproduce with the patch (but does reproduce on the latest 2.2 Flame nightly.)

Leaving qawanted to see if anyone else can produce this new issue while I am testing the 2.1 and 2.0 patched gaia.

Device: Flame 2.2
Build ID: 20150401002624
Gaia: cf90b7fc928a938e5b7181cae8b47b20c59b4e14
Gecko: 20b67213a047
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

Comment 52

[Brogan Zumwalt [Inactive]]

For clarification, I meant to say that the issue of the greyed out fmd toggle does not reproduce with the patch.

Comment 53

[JR Conlin [:jrconlin,:jconlin]]

We determined that the initial "long" clientid was generated as a backup ID. Normally, the clientID is taken from the FxA UserID embedded in the assertion validation result, but something was causing that to fail, which triggered the secondary ID generation. Subsequent shorter IDs were valid FxA UserIDs. 

I've removed some legacy code and altered some logic on the server to simply fail the assertion (with logging) if the UserID cannot be properly pulled. (See https://github.com/mozilla-services/FindMyDevice/pull/335) If the assertion cannot be properly dealt with, the server will return a 401 and require the client to log in again. Valid clientIDs should be 32 characters in length. 

I'll note that when testing with the assertion provided in the logs which returned the "long" clientId, I was unable to reproduce.

Comment 54

[Guilherme Gonçalves [:ggp]]

Replying to three different comments...

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #53)
> If the assertion cannot be properly dealt with, the server will return a 401 and
> require the client to log in again.

Great! We absolutely don't want to dissolve the 1:1 association between assertions and clientids.

(In reply to Brogan Zumwalt [:BroganZ] from comment #51)
> With the build made from
> https://github.com/lissyx/gaia/commits/bug1108166_gaia-v2.2 an issue pops up
> where at step 5 of the STR, no password prompt is required when disabling
> FMD after turning off airplane mode from notification tray.

This has been observed elsewhere in this bug (e.g., comment 12), and it's something I had seen but could never reproduce consistently. I'm pretty sure it's an intermittent FxA bug where navigator.mozId doesn't honor the refreshAuthentication option [1], and just returns an assertion right away.

Let's fire a separate bug for this if it's reproducible now.

1- https://github.com/mozilla-b2g/gaia/blob/master/apps/findmydevice/js/findmydevice.js#L498

(In reply to Alexandre LISSY :gerard-majax from comment #50)
> I have been thinking about this and I think we should land it anyway,
> because:
>  - server side issue may or may not be fixed in time
>  - it means a bug server side can break the feature of a client
>  - a "server side bug" can become a rogue server thus causing others issues
>  - in general, I don't see a good reason we should be blindly trusting
> inputs when we have the ability not to

We've discussed and agreed on this via IRC, but I thought I'd dump my opinion here. I don't think we should land this patch if we can fix this server-side in time, and even if we can't, we should still consider carefully whether there aren't other ways to solve this.

For example, one way we could approach this would be to invalidate the affected devices (or all devices?) server-side, and, when clients detect this as part of their routine heartbeat, they will attempt to re-register and obtain their correct client id. This will all happen in the background with no user interaction. And, curiously, landing this patch would prevent us from doing precisely this in the future.

I don't quite buy the security-related arguments: for a rogue server to be able to exploit this bug, it will also need to bypass HAWK, at which point it could just as well issue FMD commands. The patch wouldn't even help detect this.

Comment 55

[Brogan Zumwalt [Inactive]]

Greyed out FMD toggle issue does not reproduce on patched 2.0 Flame

When returning to Find My Device page after unlocking phone, failing to disable FMD in airplane mode, disabling phone lock and airplane mode, then disabling FMD (with password) and navigating to main settings page, the toggle for FMD is not greyed out.

Device: Flame 2.0
Build ID: 20150401000204
Gaia: 6bb15278dece68cb8d5e1a1388e53d843d01e6be
Gecko: 9c12f28cc73f
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


Blocked from testing 2.1 patched gaia by bug 1150285

Comment 56

[:gerard-majax]

Great, thanks! So indeed this was a pure server-side issue. Is the fix landed in production already ?

We should close this bug as soon as it's the case. I do have however a couple of comments.

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #53)
> We determined that the initial "long" clientid was generated as a backup ID.
> Normally, the clientID is taken from the FxA UserID embedded in the
> assertion validation result, but something was causing that to fail, which
> triggered the secondary ID generation. Subsequent shorter IDs were valid FxA
> UserIDs. 

Does this means we can get those two IDs ? Or the server will always use one or the other, but the mix is not allowed ?

> 
> I've removed some legacy code and altered some logic on the server to simply
> fail the assertion (with logging) if the UserID cannot be properly pulled.
> (See https://github.com/mozilla-services/FindMyDevice/pull/335) If the
> assertion cannot be properly dealt with, the server will return a 401 and
> require the client to log in again. Valid clientIDs should be 32 characters
> in length. 
> 

So this should automatically invalidate all the bad cases that are already live in the wild, right?

Comment 57

[JR Conlin [:jrconlin,:jconlin]]

The patch was pushed to dev. I will be filing bugs to get the code through QA and on prod as soon as it passes testing. 

as for your questions:
1) You should only get one clientID from now on: the shorter, 32 character one. 

2) This means that the longer clientIDs are no longer being generated. If an assertion fails or a clientID could not be determined, a 401 is returned to the client. If a client has stored the long ID, then subsequently does a /verify/ call and gets back a shorter clientID, the IDs will not match. The client can either discard the longer ID, request revalidation from the user, or simply fail the operation and let the user hard reset or reflash the device. It is not expected that there are many devices with longIDs. These devices could be removed from the server database, however that would immediately break any user who wishes to use the webUI to track and control their phone.

Comment 58

[Brogan Zumwalt [Inactive]]

Re: Comment 51 and reply in comment 54

The issue described with the patch is still happening on Flame 2.2 100% of the time. Once cell data reconnects after disabling airplane mode, user can disable FMD without having to input password. It DOES NOT occur on nightly 2.2, only 2.2 with the patch applied.

I am hesitant to file a bug that only occurs on a patch that hasn't been merged to master or any of the other main branches. If it is decided that the patch should be merged I will file a bug.

Device: Flame 2.2
Build ID: 20150406002503
Gaia: cf90b7fc928a938e5b7181cae8b47b20c59b4e14 (using bug1108166_gaia-v2.2 gaia branch from Lissy)
Gecko: c3335a5d3063
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

Comment 59

[:gerard-majax]

So bug 1150562 has been fixed, but last time I checked I was still getting the bogus id. When will this get to production ?

Comment 60

[Gregor Wagner [:gwagner]]

Ian, seems like the issues here are server-side related. Could you take this over and find the right assignee?

Comment 61

[Ian Bicking (:ianbicking)]

JR Conlin is on PTO until Friday, but he will be the right person to follow up with the server side.

Comment 62

[:gerard-majax]

Comment on attachment 8586661 [details] [diff] [review]
debug-fmd.patch v3 workaround

Should be fixed server-side, not client-side.

Comment 63

[JR Conlin [:jrconlin,:jconlin]]

Looking at the exchange between a stage device and the server, I'm not seeing the client pass an "audience" element to the server as part of the verification. This means that verifications can fail, since the server has no knowledge of what audience was used to generate the assertion. I am going to have to put in some patch code to deal with that.

Comment 64

[JR Conlin [:jrconlin,:jconlin]]

Peter,
Can I get a QA test on STAGE for 1.4.7 so we can push this to prod?

Comment 65

[Josh Cheng [:josh]]

Hi Peter,
Could you help to check comment 64 from JR? Thanks!

Comment 66

[Peter deHaan [:pdehaan]]

We tested in stage and I believe that 1.4.7 has successfully landed in prod.

Comment 67

[:gerard-majax]

(In reply to Peter deHaan [:pdehaan] from comment #66)
> We tested in stage and I believe that 1.4.7 has successfully landed in prod.

I still have the toggle greyed on my device, can we make sure:
 - it's live on prod
 - we did invalidate properly to force re-registering?

Comment 68

[JR Conlin [:jrconlin,:jconlin]]

https://find.firefox.com/status/
{

    "goroutines": 17,
    "status": "ok",
    "version": "1.4.7-d219766"

}

As for forcing the client to reregister, I have not done anything on the server to trigger that, mostly because I'm not sure what could be done. I don't have direct access to the production database (for very sound reasons). If I were to craft a script that were to go through the database, look for short IDs, send a push notification to that channel to trigger an event, the clients would use their local HAWK credentials to reconnect to FMD. I don't believe that this would cause the clients to re-register. If i were to delete the record after sending the push, then the HAWK would fail which would cause the server to reject the connection. Would that trigger the re-credentialing on the client?

Comment 69

[:gerard-majax]

I don't really know, and ggp might be unavailable now :(. Should we indeed land my patch?

Comment 70

[Josh Cheng [:josh]]

Hi Mark, Hi Guilherme,
Just a soft reminder. Could you help to check comment 69?
Thanks!

Comment 71

[JR Conlin [:jrconlin,:jconlin]]

Be advised that the Push system recently revamped production to address a number of issues related to the initial rollout. (see https://github.com/mozilla-services/autopush/issues?q=is%3Aissue+is%3Aclosed )

These included a number of connection issues which would have caused problems with FindMyDevice. 

Testing with my device in the US, I was able to reliably reconnect and relocate my phone, however I did have to "toggle" push by placing the phone in airplane mode for a minute, which would force the device to reconnect. 

It is suggested to retest to see if this remains a problem for other devices.

Comment 72

[Mark Goodwin [:mgoodwin]]

(In reply to Alexandre LISSY :gerard-majax from comment #69)
> I don't really know, and ggp might be unavailable now :(. Should we indeed
> land my patch?

If the changes alluded to in comment 71 do not resolve the issue, I'm happy to do some testing to see if the suggestion in comment 68 would work. If neither does the trick, let's land the patch.

Comment 73

[Josh Cheng [:josh]]

Hi Pete,
Can you check again whether the issue still exist per comment 71?
Thanks

Comment 74

[Josh Cheng [:josh]]

Hi Gerry,
Can you also help to try the patch per comment 49?
Thanks!

Comment 75

[Gerry Chang [:gchang]]

Hi Derek,
I can't recreate this issue. In comment #25, you can recreate this issue in 3.0.
Can you help to verify the patch per comment #49?

Comment 76

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Moving NI

Comment 77

[Hermes Cheng (inactive after July 27, 2015)]

Peter, could you help here?

Comment 78

[Peter Bylenga [:PBylenga]]

Brogan can you take a look at the patch?

Comment 79

[Josh Cheng [:josh]]

[Blocking Requested - why for this release]:
Nominate to future release and continue investigation.

Comment 80

[:gerard-majax]

(In reply to Josh Cheng [:josh] from comment #79)
> [Blocking Requested - why for this release]:
> Nominate to future release and continue investigation.

There is no patch to land because it was a server-side issue and the client fix workaround was not an acceptable fix. This would only concern devices already registered with the wrong id.

Comment 81

[Michael:mtreese]

moved to tracking based on comment 80.

Comment 82

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

Qawanted to check comments 73-75

Comment 83

[zouyi(Leave from Mozilla)]

According to comment 75, after building patch, this bug can be reproduced on latest build of Flame KK v2.5 by the following 

different STR:

STR: 
1) Set up the passcode lock on the settings.
2) Unlock the phone with passcode. 
3) Tap settings button on homescreen.
4) Tap Find My Device on the settings.
5) Tap "Create account or sign in" button.
6) Tap "Enable Find My Device" button.

Actual results: the button is greyed out and the user will not be able to disable it unless they reset the phone and sign out.
See attachments: logcat_1803.txt, Flame KK v2.5.3gp.
Reproduce rate: 5/10

Device: Flame KK 2.5(Affected, use patch)
Build ID               20150911133314
Gaia Revision          6280500a6cb8d1b178cdd163450e36d22846fbed
Gaia Date              2015-09-10 11:38:24
Gecko Revision         n/a
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.rose.20150902.091140
Firmware Date          Wed Sep 02 09:12:03 CST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Comment 84

[zouyi(Leave from Mozilla)]

Hi Jayme,

Please check the result in comment 83. thanks.

Comment 85

[zouyi(Leave from Mozilla)]

Attachment: logcat_1803.txt

Comment 86

[zouyi(Leave from Mozilla)]

Attachment: Flame KK v2.5 patch.3gp

Comment 87

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

Alexandre please see comment 83.  Your patch from comment 49 apparently still has the bug reproducing when applied.

Comment 88

[Pi Wei Cheng [:piwei] (inactive)]

Request fulfilled at comment 83.

Comment 89

[:gerard-majax]

(In reply to Jayme Mercado [:JMercado] from comment #87)
> Alexandre please see comment 83.  Your patch from comment 49 apparently
> still has the bug reproducing when applied.

The fix should be server-side.

Comment 90

[JR Conlin [:jrconlin,:jconlin]]

The 1.5.1 version of Push (with the TCP reconnect issue noted in comment #71) was deployed 2105-09-02

https://bugzilla.mozilla.org/show_bug.cgi?id=1201293#c3

I have verified that I am able to set and unset the "Enable Find My Device" on my Flame running 2.2.0.0-prerelease both with and without lock code.

Comment 91

[JR Conlin [:jrconlin,:jconlin]]

OBE by FXos sunset