Closed Bug 1058729 Opened 10 years ago Closed 10 years ago

[Find My Device] Users are unable to disable Find My Device

Categories

(Firefox OS Graveyard :: FindMyDevice, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: jdegeus, Assigned: qdot)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-flame-test-run-1])

Attachments

(1 file, 1 obsolete file)

Attached file logcat_20140826_0943.txt (obsolete) (deleted) —
Description: When users sign-in to their Firefox Account and enable Find My Device, if the user attempts to disable FMD, users will see the toggle switch turns grey for a few seconds but never actually disables. Repro Steps: 1) Update a Flame to 20140825040204 2) Enter Settings> Find My Device> Sign into an account> Enable FMD 3) Tap on toggle switch again to disable FMD and observe Actual: Users are unable to disable FMD once enabled Expected: Tapping on toggle switch after FMD has been enabled, disables FMD Environmental Variables: Device: Flame Master (319mb) Build ID: 20140825040204 Gaia: e424c85eda87a40c0fa64d6a779c3fa368bf770b Gecko: daa84204a11a Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: 3/3 Link to failed test case: https://moztrap.mozilla.org/manage/case/12870/ See attached: Logcat and screenshot http://youtu.be/ac9jDMICqtI
This issue DOES occur on Flame 2.1 (519mb), Open C 2.1 Actual: Users will be unable to disable Find My Device Flame 2.1(512mb) Environmental Variables: Device: Flame Master BuildID: 20140825040204 Gaia: e424c85eda87a40c0fa64d6a779c3fa368bf770b Gecko: daa84204a11a Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Open C 2.1 Environmental Variables: Device: Open_C Master Build ID: 20140825040204 Gaia: e424c85eda87a40c0fa64d6a779c3fa368bf770b Gecko: daa84204a11a Version: 34.0a1 (Master) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------------------------- This issue DOES NOT occur on Flame 2.0 (319mb), Open C 2.0 Actual: Users are able to disable FMD Flame 2.0 (319mb) Environmental Variables: Device: Flame 2.0 BuildID: 20140825000201 Gaia: 4c8b5ced1966079086d86dec3098ecf340881306 Gecko: b0545e46d08b Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Open C 2.0 Environmental Variables: Device: Open_C 2.0 Build ID: 20140825000201 Gaia: 4c8b5ced1966079086d86dec3098ecf340881306 Gecko: b0545e46d08b 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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Please remove the audio from your video.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(jdegeus)
My apologies, my edits must have not saved correctly. Please disregard URL provided in Comment 0/Description. URL without Audio: http://youtu.be/JHByn9wUJGU
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(jdegeus) → needinfo?(ktucker)
[Blocking Requested - why for this release]: This is a regression from 2.0. The user should be able to disable "Find my device" so nominating this 2.1?
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Component: Gaia::Contacts → FindMyDevice
Flags: needinfo?(ktucker)
QA Contact: ddixon
Comment on attachment 8479175 [details] logcat_20140826_0943.txt I confirm that the usr build is the only one where the problem occurs. Let's find the regression window with these builds. By the way, the logcat provided does not contain any information on Find My Device. To enable find my device logs, you need to do these extra steps: https://wiki.mozilla.org/User_Services/Try_FMD#Debugging. I mark this logcat as obsolete then.
Attachment #8479175 - Attachment is obsolete: true
Striking the regression-window tag; we can not do a regression window on a nightly only issue - we do not have a repository of nightly builds with the exception of 1 a day (which would create a giant pushlog with no ability to proceed to a secondary (narrower) pushlog in an inbound branch). And not enough back-access via the PVT site. We CAN however get you a correct logcat - adding QA-Wanted tag for log-cat.
QA Contact: ddixon
Providing a Find My Device logcat according to Comment 5.
Attached file FMD_locgat (deleted) —
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
regression and blocking 2.1
Assignee: nobody → 6a68
blocking-b2g: 2.1? → 2.1+
(In reply to Joshua Mitchell [:Joshua_M] from comment #6) > Striking the regression-window tag; we can not do a regression window on a > nightly only issue - we do not have a repository of nightly builds with the > exception of 1 a day (which would create a giant pushlog with no ability to > proceed to a secondary (narrower) pushlog in an inbound branch). And not > enough back-access via the PVT site. > > We CAN however get you a correct logcat - adding QA-Wanted tag for log-cat. A 12 hour window is still better than nothing - that could help the developer narrow down where the problem is. Why can't we test this on tinderbox builds?
QA Whiteboard: [QAnalyst-Triage+]
> A 12 hour window is still better than nothing - that could help the > developer narrow down where the problem is. Why can't we test this on > tinderbox builds? Comment 5 > "I confirm that the usr build is the only one where the problem occurs. Let's find the regression window with these builds." which was confirmed by the QA Contact (Duane) prompting my comment 6. but we'll get you the 12-hour window.
QA Contact: ddixon
I find it really odd that FMD currently has two bugs (this one and bug 1058978) in which basic features are broken, but only on the 2.1 user builds. Is it possible that something is up with the 2.1 user builds? Jason, do you happen to know who generates the user builds? Maybe they would have some insight into what, if anything, has changed with this release.
Flags: needinfo?(jsmith)
Nick might be able to help you out here.
Flags: needinfo?(jsmith) → needinfo?(nthomas)
I'm not aware of any issues in 2.1 vs 2.0 in the configuration for the builds, and would suggest looking for gaia/gecko source problem. Also, from a quick glance the on-change (dep) builds should have the same functionality as dep builds, so a regression window should be possible with the builds in https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame/ (sorry, not a public link). There's 3 months of builds there, and if the problem resolves to a merge from b2g-inbound use https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/b2g-inbound-flame/ to bisect further.
Flags: needinfo?(nthomas)
Thanks, Jason and Nick. Could someone in QA try again to generate a regression window?
Flags: needinfo?(ddixon)
Mozilla Inbound Window Last Working Device: Flame 2.1 Build ID: 20140819163010 Gaia: de7235e41f36a23a31c5e47218473c0cc471b019 Gecko: 28ccb18dc241 Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First Broken Device: Flame 2.1 Build ID: 20140819193025 Gaia: df39c463259d348396ef7f143c2c780eeb8f02d8 Gecko: 1cebb180893a Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Last Working Gaia and First Broken Gecko Issue DOES occur here. Gaia: de7235e41f36a23a31c5e47218473c0cc471b019 Gecko: 1cebb180893a Last Working Gecko and First Broken Gaia Issue DOES not occur here. Gaia: df39c463259d348396ef7f143c2c780eeb8f02d8 Gecko: 28ccb18dc241 Gecko Pushlog: hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=28ccb18dc241&tochange=1cebb180893a
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Flags: needinfo?(ddixon)
I see settings API landings in this range. Kyle - Could that be the cause of this regression?
Flags: needinfo?(kyle)
Notice the backout commit after the settings landing in that range. Settings did not land and stick until August 31. This line in the logcat that repeats on every try might be good to look at: 08-28 19:48:47.761 1539 1539 I GeckoDump: [findmydevice] end high priority section, reason: "clientLogic" 08-28 19:48:47.761 1539 1539 I GeckoDump: [findmydevice] releasing one wakelock, wakelocks are: {"clientLogic":[],"command":[]} 08-28 19:48:47.761 1539 1539 E GeckoConsole: [JavaScript Error: "TypeError: this._highPriorityWakeLocks[reason].pop(...) is undefined" {file: "app://findmydevice.gaiamobile.org/gaia_build_defer_index.js" line: 113}]
Flags: needinfo?(kyle)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Ok. While settings isn't the cause of this regression, I think I might know what is. While working on bug 1065128, I found that the Identity API tries to fire an "Unwatch" message as part of its shutdown in the inner-window-destroyed observer (see https://bugzilla.mozilla.org/show_bug.cgi?id=1065128#c14). This causes a permissions error in IPC, so the unwatch never actually happens (settings also tries to do this and has similar problems, but I don't believe that's what is causing this error). I /think/ the solution here is to call Unwatch on dom-window-destroyed. I'm going to try to fix both of these at once and see what happens. I /guess/ I can take assignment on this, but if it doesn't work I won't be able to do much more
Wow, nice detective work! Feel free to reassign to me if your idea doesn't work out.
Assignee: 6a68 → kyle
Depends on: 1065128
We were thinking that this bug would be fixed as a result of bug 1065128 being fixed. Since that bug has landed, could someone in QA see if this bug is still reproducible?
Flags: needinfo?(ddixon)
Keywords: qawanted
QA Contact: ddixon → aalldredge
Issue DOES occur in latest Flame 2.1 Aurora build. Device: Flame 2.1 Build ID: 20140918063011 Gaia: 379e68fe729a684fa2fcddb30ea1e65508db73e1 Gecko: f61e00dd4325 Version: 34.0a2 (Master) Firmware Version: L1TC00011650 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------------------------------------------------------------------------------- Issue DOES NOT occur in latest Flame Cental 2.2 build. Device: Flame Master (2.2) Build ID: 20140917223000 Gaia: d37950eb09e28aa18d0e01df9ff90574bd4337e0 Gecko: 426497473505 Version: 35.0a1 (Master) Firmware Version: v165 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(ddixon) → needinfo?(jmitchell)
Keywords: qawanted
QA Contact: aalldredge → ddixon
We haven't uplifted bug 1065182 to aurora yet, it's just on m-c. So that could be a good sign for this being fixed.
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
Bug 1065128 landed to aurora today, so re-qawanted'ing for v2.1.
Flags: needinfo?(ddixon)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [lead-review+]
(In reply to Kyle Machulis [:kmachulis] [:qdot] (USE NEEDINFO?) from comment #25) > Bug 1065128 landed to aurora today, so re-qawanted'ing for v2.1. i think you're asking for verification after uplifting, so adding the verifyme keyword for QA action.
Keywords: verifyme
Issue DOES NOT occur in Flame 9/18 build: Device: Flame 2.1 Build ID: 20140919134559 Gaia: 8923fc6755756b14b66d13c45678b53fcac6e8c5 Gecko: 8b58f3f4f05a Version: 34.0a2 Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [lead-review+] → [QAnalyst-Triage?][lead-review+][2.0-signoff-need+]
Flags: needinfo?(ddixon)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?][lead-review+][2.0-signoff-need+] → [QAnalyst-Triage+][lead-review+]
Ok. We'll call it caused by bug 1065128 then, and resolve. Yay.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
:beers: thanks again, Kyle ^_^
Verified fixed on Flame 2.2 (319mb/full flash) and Flame 2.1 (319mb/full flash) Actual result: The user is able to toggle on/off Find my device. Device: Flame 2.2 BuildID: 20141011040204 Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322 Gecko: 3f6a51950eb5 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Device: Flame 2.1 BuildID: 20141011000201 Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1 Gecko: d813d79d3eae Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: