Closed Bug 879735 Opened 11 years ago Closed 10 years ago
Investigate adu ping logic and make sure it's working right
Per bug 872712, our adu counts appear low - they don't match expected numbers based on default browser desktop installs on Nightly. We should take a look at our blocklist ping code and make sure it's working properly.
One data point - I have a non-dev oriented surface tablet that stays in the family area of the house. It has had nightly on it for a few months. I was checking adu config and noticed that the extensions.blocklist.pingCountTotal was at 6. That seems really low.
Up to 8 today after being suspended for a couple days.
jjensen is testing on a non-touch lenovo, and isn't seeing appropriate prefs for the adu ping. Specifically he's seeing: extensions.blocklist.detailsURL extensions.blocklist.enabled extensions.blocklist.interval extensions.blocklist.pingCountVersion extensions.blocklist.url which are the defaults we create. What he is missing is: app.update.lastUpdateTime.blocklist-background-update-timer which is set by the update timer service when it initializes a timer - http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateTimerManager.js#216 plus missing extensions.blocklist.pingCountTotal and extensions.blocklist.pingCountVersion prefs indicating the device never downloaded the blocklist. Juan, curious if QA might have the time to do some testing of adu pings with fresh profiles?
With fresh profiles I see the same thing as Jim describes in comment #3, when I checked right after installing. In the case of the desktop version, I can trigger a background blocklist ping and then I get the missing extensions.blocklist.pingCountTotal and app.update.lastUpdateTime.blocklist-background-update-timer preferences. For Firefox Metro I tried changing the value of extensions.blocklist.interval to a smaller number (60) and after a restart the preferences appeared. I don't remember the logic of the timers, but the blocklist ping will happen once a day (86400secs). I don't remember when, after starting up the browser, the first ping happens.
Summary: Investigate adu ping logic and make sure it's working right → Defect - Investigate adu ping logic and make sure it's working right
Whiteboard: feature=defect c=tbd u=tbd p=0
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=data_submission u=tbd p=0
No longer blocks: metrov1defect&change
Summary: Defect - Investigate adu ping logic and make sure it's working right → Work - Investigate adu ping logic and make sure it's working right
Whiteboard: feature=defect c=data_submission u=tbd p=0 → feature=work
By setting app.update.log to true you can get additional logging out of nsUpdateTimerManager.js that should help you to see if this timer and other timers are firing.
Summary: Work - Investigate adu ping logic and make sure it's working right → Investigate adu ping logic and make sure it's working right
Whiteboard: feature=work → [feature] p=0
I did some debugging here and afaict, things are working right. The blocklist ping isn't based on an idle timer, it's based on an update timer that fires every 24 hours. You can tweak a few settings to get this firing more often and then experiment around with suspending the browser - app.update.log = true extensions.blocklist.interval = 90 extensions.logging.enabled = true Using these my test involved: 1) waiting for the first blocklist ping (occurs 120 seconds after startup) 2) waiting for the next blocklist ping (90 seconds later) 3) suspending the browser for five minutes 4) resuming the browser and stay active in it On resume I always see a blocklist ping shortly after the browser wakes up.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.