Cellular Data Duration Test 12:55 p.m. Battery: 55% Located device on FMD Closed website Lock device 1:00 p.m. Log onto website. 5 minutes device not located. Signed off of website. 1:12 p.m. Device is still unable to locate. Signed off of website, will wait for a while before attempting to sign in again. 1:45 p.m. Device is still unable to locate, however, device is receiving push notifications. When Lock Screen action was sent from website, geolocation was triggered. These are all short-term tests though, we need a long-term test. And by that, I mean that I will attempt to Find My Device after 2 hours and see what happens. 3:43 p.m. Cannot connect to device. tl;dr: After 2 hours of your device being locked/left alone, you will no longer be able to connect to Find My Device.

To clarify, this occurs on full memory on Flame 2.0

This has been reproduced 3 times so far.

Unlocking the device did not immediately result in being reconnected with FMD. Toggling FMD in the menu resulted in being reconnected with FMD.

hey dougt, this seems like a rather deep gecko bug? any thoughts on who could diagnose/fix?

I will do a build with debug logs enabled for the push service. I want to check first if we are able to receive push notifications while the phone is sleeping.

This might be a Flame specific bug. We're able to get PUSH when the phone is sleeping on other devices.

I can repro this with the Open C, here's the logs with gaia debug traces enabled: https://pastebin.mozilla.org/5604146 STR: 0) enable FMD, remove device from USB 1) login to https://find.firefox.com 3) phone is located, etc 4) allow phone to sit idle (80% battery) for 2 hours; it's asleep. Screen is black 5) go to website, phone is still located but the orange spinner is going, try to play sound to no avail 6) refresh the page; no map avail, just binoculars with spinner 7) plug phone into USB (and therefore wake up) Results: phone rings and is located immediately. I have not idea if the logs will capture this adventure but let know if I need to jigger the STR or if :fabrice adds some logging, I'm happy to re-test.

I got the same results as Erin on my side, but could not get what I wanted from any logs. I wonder if we shutdown radio and wifi when the device is asleep. Vicamo, do you know?

Fabrice, wifi shuts down after what appears to be 10 minutes. According to Edgar Chen, all processes are shut down when the device goes to sleep.

(In reply to Fabrice Desré [:fabrice] from comment #8) > I got the same results as Erin on my side, but could not get what I wanted > from any logs. > > I wonder if we shutdown radio and wifi when the device is asleep. Vicamo, do > you know? RIL on Flame is not under Mozilla's control.

What about the RIL that ships on production devices? do we know if the data connection/wifi shuts down? also if it does, after what time interval? if both data/wifi connections shutdown, Push notifications will not work (except for networks that support UDP ping).

Moving over to Vendcom, removing QA-Wanted because we don't have the ability to test the "correct" RIL

Until it's proven replicable on a MozRIL running device, I cannot and have no interest on investigating the proprietary RIL stack on Flame for this.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #13) > Until it's proven replicable on a MozRIL running device, I cannot and have > no interest on investigating the proprietary RIL stack on Flame for this. Hi Vicamo, not sure about this, but as I rememeber, once we flash the 2.0 Gaia/Gecko into Flame, the MozRIL will start to work to replace the QCT RIL. Is that still true? if so, then this issue is in fact happened on Moz RIL. Could you help to clarify? Thanks for your help

(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #14) > (In reply to Vicamo Yang [:vicamo][:vyang] from comment #13) > > Until it's proven replicable on a MozRIL running device, I cannot and have > > no interest on investigating the proprietary RIL stack on Flame for this. > > Hi Vicamo, not sure about this, but as I rememeber, once we flash the 2.0 > Gaia/Gecko into Flame, the MozRIL will start to work to replace the QCT RIL. > Is that still true? if so, then this issue is in fact happened on Moz RIL. > Could you help to clarify? > > Thanks for your help Please ignore Comment#14, will update here if we finally conclude that this bug happens on MOZ RIL devices Thanks Vance

(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #14) > (In reply to Vicamo Yang [:vicamo][:vyang] from comment #13) > > Until it's proven replicable on a MozRIL running device, I cannot and have > > no interest on investigating the proprietary RIL stack on Flame for this. > > Hi Vicamo, not sure about this, but as I rememeber, once we flash the 2.0 > Gaia/Gecko into Flame, the MozRIL will start to work to replace the QCT RIL. > Is that still true? if so, then this issue is in fact happened on Moz RIL. > Could you help to clarify? > > Thanks for your help Vance is right, when we flash 2.0 gaia/gecko on the flame, the QC RIL is replaced with the Moz RIL. So with the Flame base image of v122 or v123 we are testing against Moz RIL. Vicamo, what exactly are you asking to help debug this?

(In reply to Joshua Mitchell [:Joshua_M] from comment #12) > Moving over to Vendcom, removing QA-Wanted because we don't have the ability > to test the "correct" RIL Erin indicated that this bug reproduces on Open C, so I don't think this is considered to be a Flame-specific RIL issue. On that regard, I think this our problem to resolve, not the vendor.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #13) > Until it's proven replicable on a MozRIL running device, I cannot and have > no interest on investigating the proprietary RIL stack on Flame for this. To my understanding, Erin already proved that this isn't a Flame-specific RIL bug in comment 7 by showing that the problem reproduces on Open C, so I don't think we can push this problem on the vendor, as a cross-device issue is considered Mozilla's problem to resolve. Does that make sense?

(In reply to Jason Smith [:jsmith] from comment #18) > (In reply to Vicamo Yang [:vicamo][:vyang] from comment #13) > > Until it's proven replicable on a MozRIL running device, I cannot and have > > no interest on investigating the proprietary RIL stack on Flame for this. > > To my understanding, Erin already proved that this isn't a Flame-specific > RIL bug in comment 7 by showing that the problem reproduces on Open C, so I > don't think we can push this problem on the vendor, as a cross-device issue > is considered Mozilla's problem to resolve. Does that make sense? Also note that there is no active support for device checking on SPRD-based devices, so we can't wait for that information here to determine if we should investigate this or not.

I'm marking qawanted here to address the original qawanted request on Open C.

The question here is: What is the desired behavior? (IMO this should be independent of the RIL?) - do we close both data and wifi when the device goes to sleep? if we do, then push will not work without 1) user intervention or 2) device receives an SMS/MTC or some such that wakes up the device

(In reply to Jason Smith [:jsmith] from comment #18) > (In reply to Vicamo Yang [:vicamo][:vyang] from comment #13) > > Until it's proven replicable on a MozRIL running device, I cannot and have > > no interest on investigating the proprietary RIL stack on Flame for this. > > To my understanding, Erin already proved that this isn't a Flame-specific > RIL bug in comment 7 by showing that the problem reproduces on Open C, Open C is actually Flame. > so I > don't think we can push this problem on the vendor, as a cross-device issue > is considered Mozilla's problem to resolve. Does that make sense? Please understand it's not "we push this problem on the vendor". It _is_ a problem on the vendor. Besides, I had been once fully committed to Flame development. After all it's a Mozilla's development phone. However, until there is an update made to revoke that current "No MozRIL on Flame" policy, I will not try to diagnose or investigate RIL related issues on Flame. You may say that I'm not helpful, you may also say that I'm not cooperative. I don't want to risk Mozilla in some lawsuits. That's all.

I used the STR in comment 7 to reproduce this issue. Actual Results: 1) Reproduced as comment 7 describes. 2) Orange spinner was present on website, but phone rang correctly when activated. 3) Orange spinner was present, clicked on "ring", phone did not activate. Refreshed page and map was activated, phone started to ring. Environmental Variables: Device: Open_C 2.0 Build ID: 20140802081130 Gaia: 9e5907995c9327f14cb5d182cee5ff16b1743ed4 Gecko: 3f7db58a354c Version: 32.0 (2.0) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

I have repro'd comment 7 on the Open2 running the latest nightly 2.0.0. build.

My original STR reproduced on the Open2 as well, so it can be safe to assume that this is not a Flame-specific issue?

From what I understand from offline discussions - there's agreement now that we can investigate this from the RIL side. If so, let's move forward here addressing Fabrice's comment above. Vicamo - Can you address Fabrice's comment above?

Just as a comment, this bug is currently being blocked by this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1049162

(In reply to Jason Smith [:jsmith] from comment #26) > From what I understand from offline discussions - there's agreement now that > we can investigate this from the RIL side. If so, let's move forward here > addressing Fabrice's comment above. > > Vicamo - Can you address Fabrice's comment above? I did not see any "agreement" made, even in that drivers' meeting notes. That says "... is confirming", "we are discussing ...", "can we ...", "should be fine ...", "we do not have ....".

is this a push client bug or a possible memory pressure bug? need help from :NSM

Bevis, Vicamo is in PTO this week. Please help to check if this bug related to SMS function. Thanks.

(In reply to Fabrice Desré [:fabrice] from comment #8) > I got the same results as Erin on my side, but could not get what I wanted > from any logs. > > I wonder if we shutdown radio and wifi when the device is asleep. Vicamo, do > you know? No, gecko doesn't shutdown radio in this case.

(In reply to Ken Chang[:ken] from comment #30) > Bevis, Vicamo is in PTO this week. Please help to check if this bug related > to SMS function. Thanks. No, after testing, the push notification is not related to the SMS/WAP Push.

This is very likely similar to bug 1034300. I am going to wait a bit on that, and meanwhile get myself a Flame to try these things out.

Uh, are we sure this needs to be 2.0 blocking? I would hate to not ship because of this bug. It's not clear to me who owns this and will ensure it gets settled before Code Complete, which is basically one week out (1 September). Reading the scrollback, I'm also not 100% clear on whether QA (other than Kate, who's back in school now) was ever able to repro this, or what the *actual user impact* will be. nsm, preeti, vishy, thoughts?

It was repro'd several times.

I have a flame! Is there a specific version of b2g I should flash to test this or will any 2.0 build do?

Whoops, Preeti is gone, paging Bhavana instead. nsm: I'm not sure, I've never repro'd this bug. Maybe the QA contact knows?

I'm not sure if you could use any b2g version, but for my investigation of this bug I used a tinderbox engineering build on an Open_C. Hope this helps! (please refer to comment 23 for more details) Environmental Variables: Device: Open_C 2.0 Build ID: 20140802081130 Gaia: 9e5907995c9327f14cb5d182cee5ff16b1743ed4 Gecko: 3f7db58a354c Version: 32.0 (2.0) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

So I'm on yesterday's nightly of gecko and gaia, and haven't been able to reproduce this. Both times I've had the device idle for about 2 hours, but was still able to locate and ring it. I do have calendar reminders and stuff on this enabled. I wonder if that is causing the phone to not go completely to sleep?

I didn't have any reminders or ringers set when I could reproduce this.

Marking steps-wanted to get STR clarified here.

I can't repro currently due to no Sim Card, this requires Sim Card to repro but this was my last STR: - New Flash (using Taipei Tool) - Sign into FMD, enable - Sign into website, verify that it is located - Make sure device isn't connected through USB - Leave alone for 2+ hours - Should not connect when signing onto website * Last when I tested this, I was blocked by https://bugzilla.mozilla.org/show_bug.cgi?id=1049162 to see if I could use a silent alarm to prevent this bug from happening *

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #37) > Whoops, Preeti is gone, paging Bhavana instead. > > nsm: I'm not sure, I've never repro'd this bug. Maybe the QA contact knows? I agree, If this is specific to 1 person reproducing I would not block. Lets give sometime to QA to confirm this at which point we can kick it off the blocking list if needed.

I had a chat with nsm yesterday and feel that if it is not consistently reproducible we should downgrade the bug. Also the component should be Dom? as the error if any is in simple push and not FMD Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1034300 flashing v123 does not reproduce this issue

I'm not sure but this may be the same issue I have been hitting constantly where I need to switch off and on the geolocation to get FMD website to be able to connect to my device. I reproduced the issue no later than today, on current master running on my Nexus S.

(In reply to Alexandre LISSY :gerard-majax from comment #45) > I'm not sure but this may be the same issue I have been hitting constantly > where I need to switch off and on the geolocation to get FMD website to be > able to connect to my device. I reproduced the issue no later than today, on > current master running on my Nexus S. Whenever you do that, FMD starts using a new push endpoint. So yes, if it's a push failure, it is possible that requesting a new endpoint would solve it I guess (but I know nothing about the inner workings of push).

(In reply to Alexandre LISSY :gerard-majax from comment #45) > I'm not sure but this may be the same issue I have been hitting constantly > where I need to switch off and on the geolocation to get FMD website to be > able to connect to my device. I reproduced the issue no later than today, on > current master running on my Nexus S. Is the Nexus S an officially supported device? If yes, can QA repro? If no, can you please try to repro on a Flame?

I was NOT able to reproduce this on the latest Flame build (tinderbox-Eng) Actual Results - unlocking device after a 2-hour soak and hitting refresh allows the page to update and the device is successfully found. (tested twice with 2-hour soak) Device: Flame Master Build ID: 20140901224717 Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c Gecko: c360f3d1c00d Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

(In reply to bhavana bajaj [:bajaj] from comment #43) > (In reply to Jared Hirsch [:_6a68] [@6a68] from comment #37) > > Whoops, Preeti is gone, paging Bhavana instead. > > > > nsm: I'm not sure, I've never repro'd this bug. Maybe the QA contact knows? > > I agree, If this is specific to 1 person reproducing I would not block. > Lets give sometime to QA to confirm this at which point we can kick it off > the blocking list if needed. Hey Bhavana - See comment 48, looks like QA is unable to repro. Do you want them to keep trying or just remove the nom?

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #47) > (In reply to Alexandre LISSY :gerard-majax from comment #45) > > I'm not sure but this may be the same issue I have been hitting constantly > > where I need to switch off and on the geolocation to get FMD website to be > > able to connect to my device. I reproduced the issue no later than today, on > > current master running on my Nexus S. > > Is the Nexus S an officially supported device? If yes, can QA repro? If no, > can you please try to repro on a Flame? I don't get your point, there is nothing device specific for this. I'm using the Flame to work, the Nexus S to dogfood and expose bugs. And nothing prevents this issue to be intermittent, which may make it harder to reproduce properly.

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #49) > (In reply to bhavana bajaj [:bajaj] from comment #43) > > (In reply to Jared Hirsch [:_6a68] [@6a68] from comment #37) > > > Whoops, Preeti is gone, paging Bhavana instead. > > > > > > nsm: I'm not sure, I've never repro'd this bug. Maybe the QA contact knows? > > > > I agree, If this is specific to 1 person reproducing I would not block. > > Lets give sometime to QA to confirm this at which point we can kick it off > > the blocking list if needed. > > Hey Bhavana - See comment 48, looks like QA is unable to repro. Do you want > them to keep trying or just remove the nom? I think we can close this out then.