I connected to the site https://find.firefox.com/, signed in and located my phone (purely for testing purposes). Then I closed the tab and thought no more of this. I noticed 2 hours later, that the battery had been drained much quicker than usual and I saw the geolocation icon still active in the taskbar. I checked that no app used it, even restarted the phone. But the geoloc service came back. I reopened the tab, signed out, waited... I had to restart the phone to get rid of the geoloc service. It's a problem because, if you forget to sign out from FMD, your battery will just be drained quickly without doing anything. There should be a timeout on FMD coupled to avoid this. If no activity on FMD for 5 minutes, sign out automatically. And stop using geoloc service on the phone. I know we can decativate geoloc in the phone, but it's only a workaround in this case. Gaia 9725d188a733a4aeebcfcf4c52d28e1ad8a2ba6f SourceStamp 05c6a4fed6bc BuildID 20141002000208 Version 32.0
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
This is an interesting question: do we want to keep tracking the user if they have logged out of the FMD website / closed the window? It might just be a waste of battery, unless we have plans to let users do more with the data (like export the complete GPS history and hand it to the police). Because a thief might have stolen and unlocked your phone, we don't want to allow tracking to be disabled from the phone itself. This means we can't display a message like, "Your phone is still being tracked. Click here to stop tracking and conserve the battery." I can see two other legit bugs here, however: (1) The FMD website doesn't have a button to stop tracking the device, or to unlock a locked device, or to stop ringing after setting a device to ring. This seems weird to me, especially since logging out doesn't seem to disable tracking on my device. (2) We could also show the user a warning message on the FMD website, something to let them know that tracking can drain the battery, so they should disable tracking once their phone is found. nchapman, thoughts? Do any/all of these seem worth filing on github?
Here's how tracking is supposed to work: - User visits the FMD site and we send the device a track command on load. - In the track command we set the duration to 60 seconds. This means the device should only send tracking information for the next 60 seconds. - Every 60 seconds, the web app sends another tracking command with a duration of 60 seconds so that we continue to get updates as long as the web app is open. - Once the user leaves the site, additional track commands won't be sent which means the device should only send tracking information for another 60 seconds at most. So it seems like something isn't working correctly if the device continues to send its location after the window/tab is closed. I think we need to do some investigation to see where this might be going awry.
Could someone in QA enable Gaia Debug Traces (in Settings > Developer), try to repro this tracking bug, and attach the output of `adb logcat` if the problem is reproduced?
Unable to reproduce this bug in Flame 2.2, 2.1 (Full Flash, nightly). Actual Results: Geolocation deactivates correctly after FMD website is closed. Note: The phone behaved as described in Comment 2. Device: Flame 2.2 BuildID: 20141029040208 Gaia: 35e87ac4324f0f3abd93dcc70d61c9f37256a0f5 Gecko: 7e3c85754d32 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 36.0a1 (2.2) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Device: Flame 2.1 BuildID: 20141030001201 Gaia: 3e585d8be5e2dffc376f83313299c9b6d53c3db4 Gecko: b643d78a23c6 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 34.0 (2.1) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2: --- → unaffected
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flore, I believe this was because of bug 1152264. Let's reopen if it's not the case.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1152264
You need to log in before you can comment on or make changes to this bug.