930474 - AMO themes ping count differs from FHR Themes info on Fennec / Android

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Ricardo Fradinho [:rfradinho]]

Metrics is collecting AMO pings for Themes usage.
Currently, there's about 200 daily AMO pings for Themes on Fennec.

Richard Newman has compared the values we get on AMO pings and the ones from FHR submissions:

"The data we have from FHR says that we have somewhere in the region of 130,000–180,000 users with themes installed on Android. (0.88% of reported documents have 1 theme, 0.22% have 2, a long flat tail has more — up to 30+ themes — and more than 98% have no theme installed.)

So one of these things is true:

• 99.9% of those users have the themes installed but disabled, if I'm right in assuming that disabled add-ons and themes don't send a ping, or
• 99.9% of our users don't have Gecko running on any particular day for long enough to send an update ping to AMO, or
• Fennec isn't sending update pings for some other reason, or
• AddonManager is lying to FHR on 99.9% of Firefox installs, or
• You're tracking XUL Fennec installs, or
• AMO isn't recording, or your analysis isn't picking up, the update pings."

Comment 1

[Ricardo Fradinho [:rfradinho]]

I've been tracking a Fennec phone in the (V)AMO logs and there's no record of any update_check ping.
Can you check that Fennec is pinging the update_check ?

Comment 2

[Richard Newman [:rnewman]]

Raw speculation: any update ping designed for desktop Gecko use is going to have a bad time on Android. Gecko doesn't run all the time, it gets killed frequently, etc. 

So even if update pings occur, they won't be reliable. They'll also savagely murder a user's battery.

How can we put the browser into a situation in which it ought to send an update check? What should we look for?

Comment 3

[Kris Maglione [:kmag]]

Yeah, we were wondering about this a few months ago, but I didn't have time to look into it and it fell off my radar.

There are a few things to consider:

1) On desktop, persona update pings only happen for the currently active theme. If those are the pings that you're looking at, then the assumptions in your first bullet point might be correct. I haven't looked into the implementation on Fennec yet, though.

2) The numbers that I was looking at when this issue came up were not update pings, but metadata pings. I don't remember whether the issue was that we weren't getting the expected number of pings, or that they just didn't include the expected number of personas. I'll have to check again.

3) AMO recording pings isn't an issue. AMO doesn't track update pings internally. It relies on analysis of server logs that happens externally.

So, to clarify some of the above, can you be a bit clearer about which data you're looking at when you look at update pings, and how you're analyzing it?

Comment 4

[Ricardo Fradinho [:rfradinho]]

Hi Kris. I'm talking about the information on the server logs you mentioned at 3). I've checked that there are no update check verifications in the weblogs though I using for 15-30m. The blocklist pings are there and appear quite fast after I start Fennec.
So I suspect that there are no persona update pings as there are in desktop version. Can this be confirmed ?

Comment 5

[Richard Newman [:rnewman]]

mfinkle, you landed Bug 551709 and Bug 596130. Can you explain how LWT add-on update checks work on Fennec?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #5)
> mfinkle, you landed Bug 551709 and Bug 596130. Can you explain how LWT
> add-on update checks work on Fennec?

The add-on update check is not LWT specific. It's the same for all add-ons.

Back when Fennec was new, we decided that add-on updates should just-happen. Pressing buttons and looking in the add-on manager was silly, especially when 99% of our users don't care - they just want the stuff to work.

So, we disabled the normal extensions.update.enabled pref and created a new extensions.autoupdate.enabled pref. We hooked this to the AddonUpdateService component, which when triggered by a timer, will use the AddonManager module to fetch updates for any installed add-ons.

The timer is the same system that the toolkit add-on update system and the blocklist system use. It's based on the app.update system and is setup here:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/MobileComponents.manifest#76

The app.update system waits until the application has been running for 30 seconds, then kicks off it's "timer checks" for add-on updates and blocklist checks. Those timers usually say "only fire me once every 86400 seconds (once a day)". So if a users uses Fennec for more than 30 seconds, once a day, it's very likely that Fennec will attempt to auto-update add-ons, including LWTs.

That said, the AddonUpdateService code path might not be triggering the same URL pings that the non-auto update system uses. That would mean that it's possible that AMO server logs are not seeing the data it's expecting for AMO pings.

We could try to correct that.

Comment 7

[Kris Maglione [:kmag]]

OK, so I looked into this a bit. Persona update is triggered explicitly by the add-on manager's background update check code, governed by the extensions.update.enabled pref. That pref is false on Fennec, though, and completely different code, governed by the extensions.autoupdate.enabled pref, is used instead. So if we want persona updates, and update-based usage numbers, we need to update that code to call LightweightThemeManager.updateCurrentTheme()

Comment 8

[Kris Maglione [:kmag]]

Ah, I'm late.

Comment 9

[Kris Maglione [:kmag]]

Mark, is there a particular reason for the new codepath other than silent updates? The behavior on desktop has been silent, background updates for a while now. Is there something that would prevent us from switching back to that process on Fennec?

Blair, Mossop, thoughts?

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Kris Maglione [:kmag] from comment #7)
> So if we want persona updates, and update-based usage
> numbers, we need to update that code to call
> LightweightThemeManager.updateCurrentTheme()

Sounds reasonable

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Kris Maglione [:kmag] from comment #9)
> Mark, is there a particular reason for the new codepath other than silent
> updates? The behavior on desktop has been silent, background updates for a
> while now. Is there something that would prevent us from switching back to
> that process on Fennec?
> 
> Blair, Mossop, thoughts?

I don't know the details about the current silent background updates on desktop, but I would be OK with trying to get back on that codepath.

The Fennec code does update a local cache of featured add-ons as well, but I assume we could get that done other ways.

Comment 12

[Dave Townsend [:mossop]]

Yeah the desktop update path is completely silent these days, I don't know of a reason for Fennec to not use it and can think of many reasons why they should.

Comment 13

[Kris Maglione [:kmag]]

Moving this to toolkit, since the problem is client-side.

Comment 14

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.