Investigate adu ping logic and make sure it's working right

RESOLVED WORKSFORME

Status

defect
RESOLVED WORKSFORME
6 years ago
5 years ago

People

(Reporter: jimm, Unassigned)

Tracking

Trunk
x86_64
Windows 8.1

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
Whiteboard: [on hold]
Whiteboard: [on hold] → [triaged-on hold]
Blocks: metrov1defect&change
No longer blocks: metrov1triage
(Reporter)

Comment 1

6 years ago
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.
(Reporter)

Comment 2

6 years ago
Up to 8 today after being suspended for a couple days.
(Reporter)

Comment 3

6 years ago
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?
Flags: needinfo?(jbecerra)
Keywords: qawanted
(Reporter)

Updated

6 years ago
Whiteboard: [triaged-on hold]
Flags: needinfo?(jbecerra)
QA Contact: jbecerra
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

Updated

6 years ago
Priority: -- → P1

Updated

6 years ago
Blocks: 898785

Updated

6 years ago
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.
Blocks: metrobacklog
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
Priority: P1 → --
(Reporter)

Comment 6

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
No longer blocks: metrobacklog, 898785
Keywords: qawanted
Whiteboard: [feature] p=0
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.